Implementation method on multi-service flow over rpr and apparatus therefor

ABSTRACT

This technology handles Multiple Services Flow (MSF) Based on RPR and a way of multi-service flow over RPR. MSF is defined to work at the client RPR MAC layer and uses Fairness of RPR MAC to support services of Class A, Class B and Class C. MSF is used in configurations where flow based service is managed from provisioning. Architecturally, the link and broadcast topologies are supported also. The features of flow (Service, just like Ethernet, Frame Relay and G.702 etc) based 1+1, 1:1 and 1:N protection within 50 ms, flow (or Service flow) based BW management with symmetry and asymmetry, flow based multicast and Frame Sequence Number for Performance Monitoring of flow are highlighted in this patent.

FIELD OF THE INVENTION

The present invention relates to Multiple Services Flow (MSF) Based onRPR and a way of multi-service flow over RPR, and specifically, relatesto a data transmission method for implementing multiple service flow ina multiple service ring including a trunk pipe and at least two nodeseach with at least one flow, apparatus therefore, and the multipleservice ring thus formed.

BACKGROUND ART

The present invention claims the priority of PCT internationalapplication No. PCT/CN02/00503 of the same applicant as filed on Jul.17, 2002 describing a multiple service ring with capabilities oftransmitting and switching data, video and voice, therefore all thecontents and disclosure of PCT/CN02/00503 are incorporated in thepresent application as a part of the present application.

RPR is a data network solution developed by IEEE 802.17. Regardingnetwork and application issues.

(1) RPR can provides trunk based protection, but could not provide flowbased or service based protection within 50 ms. Just like it can provideprotection of multiplex section and regeneration section of SDH/SONET,but does not have virtual container or path based protection. (2) RPRcan make multicast function of node based and packet based, can not makeflow or service based multicast. (3) If RPR provides private-lineservices and QoS is required, RPR does not have QoS monitoringcapabilities for a fixed services targeting to a customer. (4) RPR doesnot have a capability of providing a service with asymmetricalbandwidth. (5) If a customer needs more bandwidth than a standardbandwidth with granularity ITU-T Recommendation defined. RPR can notimplement that, just like three times 100 Mbps. (6) When a customerneeds a security filtering function for Layer 2, Layer 3 and layer 4,RPR does not have this function. (7) When a carrier needs loopbacktesting function of flow based, RPR could not do that. (8) RPR has agood application for two-fibre ring, but for other topologies, just likefour-fibre ring, link topology and add/drop flow topology, it still havea problem.

The expansion of business and metro use of data network services aredriving the need to deploy data services infrastructure facilities withpre-plan method in the way of flow or service. The dynamic bandwidthallocation and differentiated services over an trunk pipe, flow basedbandwidth management, security function, protection, multicast,performance monitoring and their applications in the differenttopologies are the basic requirements of carrier class.

SUMMARY OF THE INVENTION

The object of the present invention is to develop Multiple services flowbased on RPR and to provide the following capabilities:

-   (1) The Technology encapsulation and transport of Ethernet, Frame    Relay, G.702 PDH circuit—Synchronous and asynchronous circuit    transport, Video signal, voice-band signal, Digital channel    supported by 64 kbit/s-based ISDN etc over a two-fibre ring, a    link-type and broadcast topology of fibres.-   (2) Service (or flow) based protection of 1+1, 1:1, and 1:N models    within 50 ms.-   (3) Service (or flow) based multicast and station-based multicast    and broadcast.-   (4) Bandwidth limitation of service (or flow) based with symmetry    and asymmetry.-   (5) Flow merging with symmetry and asymmetry.-   (6) Line-speed filtering of flow based.-   (7) Flow based performance monitoring in 15-minute and 24-hour.-   (8) Mirroring of flow.-   (9) Frame based transparent PPPoE and PPPoA transport from access to    backbone along a MSF ring or other topologies, in order to simplify    accounting mechanism (e.g. Radius), reduce maintenance work, and    improve latency variation (compared to Layer 2 and Layer 3 switch)    in Access network application.

To achieve the above objects, the present invention provides a datatransmission apparatus for implementing multiple service flow in amultiple service ring including a trunk pipe and at least two nodes eachwith at least one flow, said apparatus comprising: a flow Rx framercoupled to said flows for converting data received from said flows intodata packets of a predetermined protocol; transmission setup means forsetting-up information indicating the destination node address anddestination flow for the packets of said predetermined protocol to betransmitted; and a Tx framer for encapsulating said informationindicating the destination node address and destination flow and thepackets of said predetermined protocol into frames of the multipleservice ring and transmitting the same along said trunk pipe to adownstream neighbor node in the ring.

It is preferable that the data transmission apparatus of presentinvention, of which said predetermined protocol is a XP (processingprotocol), further comprises: a Rx framer for receiving and de-framingdata frames of the multiple service ring from a upstream neighbour nodealong said trunk pipe to obtain at least a destination node address andXP packets; and transiting means for transiting the frames destined toother nodes to said Tx framer so as to forward the frames destined toother nodes to a next node.

It is preferable that the data transmission apparatus of presentinvention further comprises: a destination flow determining means fordetermining a destination flow of the XP packets for a Universally orLocally administered address; and a flow Tx framer for converting saidXP packets for a node with a Universally or Locally administered addressfrom the Rx framer into data of format of local flow and sending thelocal flow data to a corresponding flow determined by said destinationflow determining means.

The present invention further provides a multiple service ring systemcomprising a plurality of nodes, each node including a data transmissionapparatus according to any one of claims 1-34, wherein each of saidnodes is assigned a node address(NA), and data incoming to a nodecontains a destination node address, and said destination node addressis XOR'ed with the NA of the local node to check for match or mismatch.

The present invention further provides a data transmission method forimplementing multiple service flow in a multiple service ring includinga trunk pipe and at least two nodes each with at least one flow, saidmethod comprising: a flow Rx framing step of receiving data from a flowand converting the received data into data packets of a predeterminedprotocol; a transmission setup step of setting-up information indicatingthe destination node address and destination flow for the packets ofsaid predetermined protocol to be transmitted; and a Tx framing step ofencapsulating said information indicating the destination node addressand destination flow and the packets of said predetermined protocol intoframes of the multiple service ring and transmitting the same along saidtrunk pipe to a downstream neighbor node in the ring.

It is preferable that the data transmission method of present invention,of which said predetermined protocol is XP (processing protocol),further comprises: a Rx framing step of receiving and deframing dataframes of the multiple service ring from a upstream neighbour node alongsaid trunk pipe to obtain at least a destination node address and XPpackets; and a transiting step of transiting the frames destined toother nodes so as to forward the frames destined to other nodes to anext node.

It is preferable that the data transmission method of present inventionfurther comprises: a destination flow determining step of determining adestination flow of the XP packets for a node with a Universally orLocally administered address; and a flow Tx framing step of convertingsaid XP packets for a node with a Universally or Locally administeredaddress into data of format of local flow and sending the local flowdata to a corresponding flow determined in said destination flowdetermining step.

This Patent provides a packet-based transport model to multiple servicesand multiple topologies for continuation and extension of ITU-T PatentX.85/Y.1321 and X.86/Y.1323. Continued compatibility with all existingrequirements and standards from ITU-T and other organizations isrequired.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitedby the figures of the accompanying drawings, in which like referencesindicate similar elements and in which:

FIG. 1 shows the Scope of patent based on RPR as a MAC client.

FIG. 2 shows Tx and Rx Diagram of a Data Node.

FIG. 3 shows a XP layer network example.

FIG. 4 shows a MDL layer network example (Connection-oriented(upper)/connectionless (bottom)).

FIG. 5 shows a Client/Server association in a MSF transport ring.

FIG. 6A shows XP layer multipoint connection points examples.

FIG. 6B shows a Flow Based 1+1 Protection.

FIG. 7 shows a Generic Protocol Stack of MSF Based on RPR.

FIG. 8 shows a Relationship between XP and RPR MAC, Upper Layer and XP.

FIG. 9 shows a Generic Frame Format.

FIG. 10 shows Expressions of FN ID and TCCR ID.

FIG. 11 shows a TDM service channel over MSF.

FIG. 12 shows Expressions of 1+1 and 1:1 flow protection parameters.

FIG. 13 shows Expressions of 1:N flow protection parameter.

FIG. 14 shows Expressions of 1+1 and 1:1 flow protection parameters.

FIG. 15 shows Expressions of 1:N flow protection parameter.

FIG. 16 shows A MSF Topology, Link-type with Adding and Dropping FlowServices.

FIG. 17 shows A MSF Topology, Broadcast Connection to DVB Application.

FIG. 18 shows A MSF Topology, Pseudo-mesh Connection.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

This technology handles Multiple Services Flow (MSF) Based on RPR and away of multi-service flow over RPR. MSF is defined to work at the clientof RPR MAC layer and uses Fairness Algorithm (FA) of RPR MAC to supportservices of Class A, Class B and Class C. MSF is used in configurationswhere flow based service is managed from provisioning. Architecturally,the link and broadcast topologies are supported also. The features offlow (Service, just like Ethernet, Frame Relay and G.702 etc) based 1+1,1:1 and 1:N protection within 50 ms, flow (or Service flow) based BWmanagement with symmetry and asymmetry, flow based multicast and FrameSequence Number for Performance Monitoring of flow are highlighted inthis patent.

Key Words of the present application are: Flow based 1+1, 1:1 and 1:Nprotection within 50 ms, Flow based bandwidth management with symmetryand asymmetry, Flow based multicast, Flow based performance monitoringin the 15-minute and 24-hour, Flow based security, RPR MAC Client,Fairness arithmetic, MAC Destination Address and Source address, LocalDestination Address and Source address, Flow Type (FT), Flow Number(FN), Frame Sequence Number (FSN).

The present invention will be described in accordance with the followingsequence:

-   1 Scope-   2 References-   2.1 ITU-T Recommendations-   2.2 IEEE Specification-   3 Definitions-   4 Abbreviations-   4.1 Abbreviations specified in IEEE 802.17-   4.2 Abbreviations specified in ITU-T I.321-   4.3 Abbreviations specified in ETSI-   4.4 Abbreviations used in this Patent-   5 Network framework of Multiple services flow Based on RPR-   5.1 Elements of Ring over MSF-   5.2 Frame Types on a Ring and Multiple Services in Flow-   5.3 Components of a Data Node in MAC Client-   5.4 Reference Point in MAC Client of a Data Node-   5.5 Transport functional architecture of MSF networks-   5.6 Operation of Network Management Frames in MAC Client-   5.7 Fault Management in MAC Client-   5.8 Performance Management in MAC Client-   6 The framework-   6.1 The Technology framework of RPR based Trunk Pipe-   6.2 MSF (client) interface to RPR MAC-   6.3 Flow Adaptation Function Unit-   7 Generic Frame Format-   7.1 Destination Address for use of this Patent-   7.2 Extended protocol field-   7.3 Payload Type (PT) Field-   7.4 Payload FCS Indicator (PFI) Field-   7.5 Reserved Field-   7.6 FT/CS/NM Field-   7.7 Flow Number (FN) Field-   7.8 Reserved Field-   7.9 Frame Sequence Number (FSN) Field-   7.10 HEC Field-   7.11 Payload of XP-   7.12 XN Payload FCS-   8 Loopback function-   8.1 Flow Loopback (TRL)-   8.2 Flow Loopback (TRL) Shortcut-   8.3 Node Reachability Verification (NRV)-   8.4 Node Reachability Verification (NRV) shortcut-   9 TDM Circuit Emulation (TCE) over MSF-   9.1 Introduction-   9.2 Technology framework of TDM Circuit Emulation (TCE)-   9.3 Services provided by MSF Data link-   9.4 Supported Functions of MSF XP for TCE case-   9.5 XP Technology involved to support TCE-   9.6 Management function involved to support TCE-   10 Flow Based Protection (FBP)-   10.1 Ethernet Flow Based Protection (TFBP)-   10.2 TCE Flow Based Protection (TFBP)-   11 Flow Based Multicast (FBM)-   12 Bandwidth Policing, Merging and Security of Flow-   12.1 Bandwidth Policing of Flow Based with symmetry and asymmetry-   12.2 Flow Merging or Bundling with symmetry and asymmetry-   12.3 Flow Based Security—Line-Speed Filtering-   13 Topology Application of Link-type and Broadcast Network-   13.1 Support of a Link-type with Adding and Dropping Flow Services-   13.2 Support of a Broadcast Connection to DVB Application-   13.3 Support of a Pseudo-mesh Topology    1. Scope

This Patent handles Multiple Services Flow (MSF) Based on RPR and a wayof multi-service flow over RPR. MSF is defined to work at the client ofRPR MAC layer and uses Fairness Algorithm (FA) of RPR MAC to supportservices of Class A, Class B and Class C. MSF is used in configurationswhere flow service is managed such that over provisioning does notoccur. Architecturally, the link and broadcast topologies are supportedalso. The features of flow (Service, just like Ethernet, Frame Relay andG.702 etc, this flow can also be named as tributary service) based 1+1,1:1 and 1:N protection within 50 ms, flow (Service) based Bandwidthmanagement with symmetry and asynmmetry, flow based multicast and FrameSequence Number for Performance Monitoring of flow are highlighted inthis Patent. MSF provides a packet-based transport model to multipleservices and multiple topologies.

FIG. 1 Shows the Scope of Patent Based on RPR as a MAC Client.

This patent is based on RPR as a MAC client and is used inconfigurations where topology and protection is provisioned. What thistechnology emphasizes is flow, but not a payload of flow; protection(1+1, 1:1 and 1:N) and multicast of flow, but not multicast of MAC; MSFpriority, but not MAC priority. The data frame, control frame andnetwork management frame in this technology is all required to map tothe payload of RPR data frame. Some control frames RPR defined are alsoused in this technology, just like topology discovery, protection andFA. All of these frames used in this technology has no relations to andis independent on the control frames (just like frames of topologydiscovery, fairness, protection) of RPR MAC layer. No change is made forall Ethernet-base protocol (including IEEE 802.3 Ethernet), all PDHstandards, Frame Relay standards, G.702/ISDN standards and ETSI DVBspecifications. This patent is mainly located at a dual-directionalsymmetric counter-rotating rings based on RPR.

NOTE 1—It is intended that technology can be extended, in futureamendments, to support additional new types of data service.

2 References

The following ITU-T Patents, and other references contain provisionswhich, through reference in this text, constitute elements of thispatent. At the time of publication, the editions indicated were valid.All Patents and other references are subject to revision: all users ofthis patent are therefore encouraged to investigate the possibility ofapplying the most recent edition of the Patents and other referenceslisted below. A list of currently valid ITU-T Patents is regularlypublished.

2.1 ITU-T Patents

-   [1] ITU-T Patent X.85/Y. 1321, IP over SDH using LAPS.-   [2] ITU-T Patent X.86/Y. 1323, Ethernet over LAPS.-   [3] ITU-T Patent X.211 (1995) | ISO/IEC 10022 (1996), Information    technology—Open Systems Interconnection—Physical service definition.-   [4] ITU-T Patent X.212 (1995) | ISO/IEC 8886 (1996), Information    technology—Open Systems Interconnection—Data link service    definition.-   [5] ITU-T Patent X.200 (1994) | ISO/IEC 7498-1 (1994), Information    technology—Open System Interconnection—Basic reference model: The    basic model.-   [6] ITU-T Patent I.363.1 (1996), B-ISDN ATM Adaptation Layer    specification: Type 1 AAL-   [7] ITU-T Patent G.805 (2000), Generic functional architecture of    transport networks    2.2 IEEE Specifications-   [8] IEEE 802.3 CSMAD/CD Access Method and Physical Layer    Specifications, 2002 Edition.-   [9] IEEE 802.17, Resilient Packet Ring Access Method & Physical    Layer Specifications—Media Access Control (MAC) Parameters, Physical    Layer Interface, and Management Parameters, October, 2002 Edition.    3 Definitions

For the purposes of this patent, the following definitions apply:

3.1 Trunk Pipe: a physical connection of two adjacent nodes. Trunk pipeis a channel of RPR based on a span of MSF.

3.2 Control Signalling Frame: a frame used to flow multicast orprotection etc in a node.

3.3 CT_Request Frame: a frame used to send a configuration table requestfrom Node A to Node B along a MSF ring.

3.4 CT_Response Frame: a frame used to send a configuration tableresponse from Node B to Node A along a MSF ring.

3.5 Configuration Table (CT): a mapping table reflecting the actualvalue of FT and FN in a node and TCCR between nodes on the MSF ringduring engineering operation or project installation phase.

3.6 Configuration Table Inquiry (CTI): a function to get CT from a node.CT_Request frame with a CTI parameter reflecting changing (or updating)part of TCCR of a node on MSF ring is sent to other nodes (called one ofthem as Node B) by unicast/multicast/broadcast mode from a node (calledNode A, e.g. Central station in the most case) by network managementinterface during normal engineering operation or project installationphase. All nodes received CT_Request frame with a CTI parameter willgive a point-to-point response by CT_Response frame with a CTI parameterreflecting actual configuration table of the local node on RPR ring toNode A.

3.7 Configuration Updating Table (CUT): a mapping table reflecting theavailable value modification of FT and FN in a node and TCCR betweennodes on the MSF ring during engineering operation or projectinstallation phase. The incorrect CUT will lead to fault of Flow on MSFring. CT_Request frame with an CUT parameter reflecting changed (orupdating) part of TCCR of all node on MSF ring is sent to other nodes bybroadcast mode from a node (e.g. Central station in the most case) bynetwork management interface during normal engineering operation orproject installation phase. All nodes received CT_Request frame willbuild corresponding mapping relations of TCCR in the local node and givea point-to-point response by CT_Response frame to that node sendingCT_Request frame. After getting CT_Response frame, that node sourcingCT_Request frame issues a CT_Confirm frame to that remote node sendingCT_Response frame.

3.8 Frame Sequence Number (FSN): A modulo used to performance monitoringbased on Flow service. This 8-bit field is used to identify FrameSequence Number (FSN) of Ethernet or TCE data frames in numbered moduloN_fsn=64 (default value, N_fsn is programmable and can be configured to256 if application needs) from 0 to 63. The field is used to performancemonitoring function for packet lost or duplicated of TCE (or Ethernet)based flow. The FSN field will be set to zero if the signalling controlframes or network management frames are used.

3.9 Initial Configuration Table (ICT): a mapping table reflecting theinitial and available value of FT and FN in a node and TCCR betweennodes on the RPR ring during engineering installation or projectinstallation phase. The ICT must be pre-installed before RPR engineeringoperation or project installation phase. The incorrect ICT will lead tofault of Flow services on RPR ring. CT_Request frame with an ICTparameter reflecting initial TCCR of all nodes on RPR ring is sent toother nodes by broadcast mode from a node (e.g. Central station in themost case) by network management interface during initial engineeringoperation or project installation phase. All nodes received CT_Requestframe will build corresponding mapping relations of TCCR in the localnode and give a point-to-point response by CT_Response frame to thatnode sending CT_Request frame. After getting CT_Response frame, thatnode sourcing CT_Request frame issues a CT_Confirm frame to that remotenode sending CT_Response frame.

3.10 Multiple Services Flow (MSF): a bi-directional symmetriccounter-rotating fibre rings, each node could add and drop one or moreindependent flows.

3.11 Multiple Services Flow over RPR: a bi-directional symmetriccounter-rotating fibre rings based on RPR and located at RPR MAC client(refer to FIG. 1), each node could add and drop one or more independentflows or services of class A, Class B and Class C, provisioned topologyand protection, IEEE 802.17 frame format, flow service based operation.

3.12 Resilient Packet Ring (RPR): It is defined by IEEE802.17, ahigh-speed network technology optimised for frame transmission over aredundant ring topology.

3.13 RPR Rx Framer: a RPR MAC framer in Rx side, it terminates a frameof IEEE 802.17 through a station via the ringlet.

3.14 RPR Tx Framer: a RPR MAC framer in Tx side, it sources or passes aframe of IEEE 802.17 through a station via the ringlet.

3.15 XP Data Node: a MSF Node that has an eastward Rx, an eastward Tx, awestward Rx and a westward Tx Trunk Pipe connections along MSF ring, andone or more adding and dropping independent flows. It also has functionsof receiving, transmitting and forwarding of network management frame,control signalling and data frame in a Node. The different connectionconfiguration is applied for the different topologies. A dual-ringstructure with a pair of unidirectional counter-rotating ringlets isdefault and major application form.

3.16 X link Protocol (XP): a data link protocol between reference pointG1/G2 and reference point T1/T2, used to communication between differentMSF nodes. The XP does operate by sending/receiving both data frame andthe associated network management/signalling frames to/from an trunkpipe of a node.

3.17 XP Rx Processor: a set of functions used to XP processing in Rxdirection. It includes Rx entity after RPR MAC, discrimination ofmulticast/broadcast, FT/FN value and other associated XP protocolprocessing.

3.18 XP Tx Processor: a set of functions used to XP processing in Txdirection. It includes Tx entity outgoing to RPR MAC, Tx schedule unit,functions of determination of NA, FT, FN, FCS, multicast/broadcast. Theother associated XP Technology processing is also included.

3.19 N_ct: a count of retransmission used to Configuration TableOperation. All nodes on a ring will wait to be assigned ICT duringengineering installation phase. After issuing CT_Request frame, Node Awill automatically send CT_Request frame again after retransmit Timer_ct(it is programmable) if Node A does not receive correspondingCT_Response frame. It is believed that Node B is not reachable after Ntimes of retransmission (N_ct is programmable also). N_ct is also usedby ICT operation.

3.20 Network Management Frame: a frame used to performance and faultmonitoring, node configuration management etc along a MSF ring or otherdifferent topologies.

3.21 Node Address (NA): an address that identifies a particular stationon a network. NA is a OUI MAC address along the RPR ring or otherdifferent topologies. IEEE assigns value of 24 bits, manufacturerassigns remaining 22—local indicates a locally administered address. Itis the responsibility of the administrator to insure uniqueness.

3.22 Reference Point G1: a reference point between RPR MAC and itsclient. It stands for processing sink of RPR MAC framer in RPR MACclient side.

3.23 Reference Point G2: a reference point between RPR MAC and itsclient. It stands for processing source of RPR MAC framer in RPR MACclient side.

3.24 Reference Point T1: a reference point between Flow Rx Framer and XPprocessor. It stands for processing sink of XP before Flow Rx framer ofTCE or Ethernet etc.

3.25 Reference Point T2: a reference point between Flow Tx Framer and XPprocessor. It stands for processing source of XP after Flow Tx framer ofTCE or Ethernet etc.

3.26 Source Flow (ST): a Flow used as multicast/broadcast source in amembership group within a node.

3.27 Timer_ct: a Timer of retransmission used to Configuration TableOperation. A node after first power-on or during the phase needed tochange configuration table on a ring will wait to be assigned ICT duringconfiguration modification or project installation phase. After issuingCT_Request frame, Node A will automatically send CT_Request frame againafter retransmission Timer_ct (it is programmable) if Node A does notreceive corresponding CT_Response frame. It is believed that Node B isnot reachable after N_ct times of retransmission (N_ct is programmablealso). N_ct is also used by CUT operation.

3.28 Transit: a passing of a frame through a station via the ringlet.

3.29 Flow: an independent adding/dropping flow (or service) channelto/from a data nodes, just like a series “Private Line or PrivateCircuit for Renting from Carrier”. Flow can be multi-service with aconstant bandwidth of symmetry and asymmetry. The different flow can beassigned to different priority.

3.30 Flow Adaptation Function Unit: an adaptation function from/tovarious independent flow type signals to/from reference point T1/T2. Ithas Flow Adaptation Source Function and Flow Adaptation Sink Function. ASink corresponds to reference point T1, a source to reference point T2.This adaptation function can include the signal and rate transform,synchronous function between two sides of peer.

3.31 Flow Cross-connection Relationship (TCCR): a table reflecting Flowcross-connection relationship of all nodes on a ring or othertopologies. It is global table of a dual-ring structure or othertopologies, that is, source and sink connection relationship of allavailable flows.

3.32 Flow Membership Copy: a duplicate function implementation fromSource Flow (ST) to every Flow in the corresponding membership groupwithin a node.

3.33 Flow Multicast/Broadcast: a discriminator of distinguishing unicastor Multicast/Broadcast packets while a packet is coming up from a RPR RxFramer via the ringlet, so as to provide TBM function. The TBM FunctionUnit built in a Node is defined to support one or more independenthierarch of multicast possibly involved the same or different FT at thesame time. TBM Function Unit implements a duplication function within anode (station) from a Flow getting a payload of a frame from the relatedtopologies to other multiple Flow with the same FT value and with beingset to have a relation of membership group. A group of FN with the sameFT value within a Node can be set to become a membership group ofmulticast/broadcast. It is required that a designated Flow in themembership group should receive data frames at the reference point G1from the related topologies (A designated Flow in the membership groupis only allowed to get packet from ST, and is not permitted to receiveall other packets). This patent defines this designated Flow as a SourceFlow (ST). Once getting data frames, the ST duplicates those frames toevery Flow in the corresponding membership group within a node. The STshould be set and designated to a given value of FT and FN by networkmanagement entity during the project installation phase or on-lineoperation phase. The one or more STs can be designated or changeddynamically within a node according to the customer requirements.

3.34 Flow Rx Framer: an abstract of physical framer of Flow at Rx side,it stands for a framer of TCE or Ethernet framer.

3.35 Flow Tx Framer: an abstract of physical framer of Flow at Tx side,it stands for a framer of TCE or Ethernet framer.

3.36 Flow Number (FN): a number of same types of Flow Port on a node.This number is 7 if the 7th ISDN is provided in a node.

3.37 Flow Type (FT): a type of an independent adding/dropping flowchannel to/from the RPR data nodes. This type can be TCE service.

3.38 Tx Schedule: a control function for transmitted frame in a nodeaccording to the priority level of (a) forwarded frames from upstreamnode, (b) multicast/broadcast frames and (c) transmitted frame from thelocal station. If there are several frames to be sent in a node at thesame time, the schedule unit will check priority of frame and decidewhich frame will go first to the downstream along the ringlet.

3.39 XP Rx Processor: a set of logical functions used to XP processingin Rx direction. It includes Rx entity from RPR MAC between referencepoint G1/G2 and T1/T2, discrimination of multicast/broadcast based onFlow, FT/CS/NM value, FN value, FSN value and other associated XPTechnology processing.

3.40 XP Tx Processor: a set of logical functions used to XP processingin Tx direction. It includes Tx entity outgoing to RPR MAC, Tx scheduleunit, functions of determination of NA, TTL, FT, PN and FSN,multicast/broadcast from the view of RPR MAC layer. The other associatedXP protocol processing is also included.

3.41 1+1 protection (flow based, unidirectional): a 1+1 protectionarchitecture has one normal traffic signal (packet), one working flow,one protection flow and a logical bridge. At the source side, the normaltraffic signal (packet) is logically bridged to both the working andprotection flow. At the sink side, the normal traffic signal (packet) isselected from the better of the two flows. Due to the logical bridging,the 1+1 architecture does not allow an extra unprotected traffic signal(packet) to be provided.

3.42 1:N protection (flow based, unidirectional): a 1:N protectionarchitecture has N normal traffic signals (packet), N working flows and1 protection flow which may have 1 extra traffic signal (packet) in caseof no defect condition (or a fault indication) or external commands forthe N working flows. The signals (packet) on the working flows are thenormal traffic signals (packet). The signal (packet) on the protectionflow may be either one of the normal traffic signals (packet), an extratraffic signal (packet), or the null signal (packet) (e.g. an all-ONEssignal, a test signal (packet), one of the normal traffic signals(packet)). At the source side, one of these signals (packet) isconnected to the protection flow. At the sink side, the signals (packet)from the working flows are selected as the normal signals (packet). Whena defect condition or a fault indication is detected on a working flowor under the influence of certain external commands, the transportedsignal (packet) is bridged to the protection flow. At the sink side, thesignal from this protection flow is then selected.

3.43 Automatic Protection Switching (APS, flow based) within 50 ms:autonomous switching of a signal (packet) from a failed working flow toa protection flow when a defect condition or a fault indication isdetected on a working flow or under the influence of certain externalcommands and subsequent restoration using control signals carried by thecorresponding control signaling packet.

4 Abbreviations

4.1 Abbreviations Specified in IEEE 802.17

This Patent makes use of the following abbreviations specified in IEEE802.17:

-   (1) DA Destination Address-   (2) FCS Frame Check Sequence-   (3) FE Fairness Eligible-   (4) HEC Header Error Check-   (5) IEEE Institute of Electrical and Electronics Engineers-   (6) LAN Local Area Network-   (7) MAC Medium Access Control-   (8) MAN Metropolitan Area Network-   (9) MIB Management Information Base-   (10) MTU Maximum Transfer Unit-   (11) OUI Organizationally Unique Identifier-   (12) PDU Protocol Data Unit-   (13) PHY Physical Layer-   (14) POS Packet Over SONET-   (15) PT Protocol Type-   (16) RI Ringlet Identifier-   (17) SA Source Address-   (18) SDU Service Data Unit-   (19) SNMP Simple Network Management Protocol-   (20) SPI System Packet Interface-   (21) TTL Time-To-Live-   (22) WAN Wide Area Network-   (23) WTR Wait To Restore    4.2 Abbreviations Specified in ITU-T I.321

This Patent makes use of the following abbreviations specified in ITU-TPatent:

-   a) ATM Asynchronous Transfer Mode    4.3 Abbreviations Specified in ETSI

This Patent makes use of the following abbreviations specified in ETSIPatent EN 300 429:

-   a) DVB Digital Video Broadcast    4.4 Abbreviations Used in this Patent-   1) AP Access Point-   2) CP Connection Point-   3) CS Control Signalling-   4) CT Configuration Table-   5) CTI Configuration Table Inquiry-   6) CUT Configuration Updating Table-   7) EFBP Ethernet Flow Based Protection-   8) ICT Initial Configuration Table-   9) LMXP Layer Management of X link Protocol-   10) LSFFU Line-Speed Filtering Function Unit-   11) MAC Media Access Control-   12) MDL MAC Data Link Layer-   13) MDLLC MDL Link Connection-   14) MDLLF MDL Link Flow-   15) MDLNC MDL Network Connection-   16) MDLNF MDL Network Flow-   17) MDLSC MDL Subnetwork Connection-   18) MDLSF MDL Subnetwork Flow-   19) MDCT MDL Trail Multipoint Connection Point-   20) MPCP Multipoint Connection Point-   21) MSF Multiple Services Flow-   22) MSF-RPR Multiple Services Flow over RPR-   23) NA Node Address of Resilient Packet Ring-   24) NM Network Management-   25) NRV Node Reachability Verification-   26) PFI Payload FCS Indication-   27) PLAS Pure Local Address Structure (32-bit)-   28) PT Payload Type-   29) OAM Operation, Administration and Maintenance-   30) RPR Resilient Packet Ring-   31) Rx Receive data-   32) ST Source Flow-   33) TBM Flow Based Multicast-   34) FBP Flow Based Protection-   35) TCCR Flow Cross-Connection Relationship-   36) TCE TDM Circuit Emulation-   37) TCP Termination Connection Point-   38) TFP Termination Flow Point-   39) TDM Time Division Multiplex-   40) TMG Flow Merging Group-   41) TRL Flow Loopback-   42) TFBP TCE Flow Based Protection-   43) FN Flow Number-   44) FT Flow Type-   45) Tx Transmission data-   46) U/M/B Unicast/Multicast/Broadcast-   47) XP X link Protocol entity as a RPR MAC client-   48) XPLC XP Link Connection-   49) XPNC XP Network Connection-   50) XP-PDU XP—Protocol Data Unit-   51) XP-SAP XP—Service Access Point-   52) XPSC XP Subnetwork Connection-   53) XP-SDU XN—Service Data Unit-   54) XPT XP Trail    5 Network Framework of Multiple Services Flow Based on RPR    5.1 Elements of Ring Over RPR MAC

MSF based on RPR employs a dual-ring structure consisting of a pair ofunidirectional count-rotating ringlets, more than one nodes of each withRPR MAC, RPR MAC Client and at least one Flow. “MSF-RPR” uses OUI MACaddresses and the multicast address in support of flow services and usesRPR frame format that allows this patent to define payload within anEthertype. MSF uses Fairness Algorithm (FA) to support services of ClassA, Class B and Class C. This patent is used in configurations where flowservice is managed by provisioning. Architecturally, the link, broadcasttopologies are supported also. Each node could add and drop one or moreindependent flows (e.g. DVB port) and control signalling frames andnetwork management frames. This patent supports multicast and broadcastof these Flow service and forwarding data packets.

5.2 Frame Types on a Ring and Multiple Service in Flow

Each node has ability of adding and dropping one or more independentFlow services defined in Table 1. TABLE 1 Types of multi-service in FlowFlow types Capabilities TCEs Full duplex point-to-point Multicast ofBroadcast of node based node based Ethernet Full duplex point-to-pointMulticast of Broadcast of node based node basedNote 1:The bandwidth of trunk pipe depends on deployment service requirements,the trunk Flow bandwidth be half of the trunk pipe bandwidth to provideprotection bandwidth availability where needed. Where servicesrequirements allow the trunk of Flow bandwidth can exceed the trunkbandwidth.Note 2:Multicast is half duplex point-to-multipoint of node based, Broadcast ishalf duplex point of node based to all other points on a ring.

Transmitted and received frames on a ring have (1) frames ofmulti-service station by station, (2) control signalling frame and (3)network management frame specified in Table 2, to show full capabilitiesof point-to-point, multicast and broadcast along a ring. TABLE 2 Frametypes Frame types Capabilities Frames of multi-service stationPoint-to-point Multicast Broadcast by station Control Signalling FramePoint-to-point Multicast Broadcast Network Management FramePoint-to-point Multicast BroadcastFIG. 2 Shows Tx and Rx Diagram of a Data Node.5.3 Components of a Data Node in MAC Client

A MSF data node is the system equipment that has an eastward Rx,eastward Tx, westward Rx and westward Tx Trunk Pipe connections, and oneor more adding and dropping independent Flows over RPR MAC. MSF nodealso has functions of receiving, transmitting and forwarding of networkmanagement frame, control signalling and data frame within a Node. Thecorresponding change should be made as the different connectionconfiguration is applied for the different topologies. The basiccomponents and elements of a node are as follows.

5.3.1 Trunk Pipe: a Physical Connection of Two Adjacent MSF Nodes.

5.3.2 Flow: an independent adding/dropping flow channel to/from the MSFdata nodes, just like a series “Private Line or Private Circuit forRenting from Carrier”. Flow can be a G.702 ports. The different flow canbe assigned to different priority.

5.3.3 Inner Ring: an inner single ring of RPR.

5.3.4 Outer Ring: an outer single ring of RPR.

5.3.5 MAC Client: The layer entity of XP that invokes the MAC serviceinterface.

5.3.6 Transit: a passing of a frame through a station via the ringlet.

5.3.7 Schedule Unit: a control function for transmitted frame within anode according to the priority level of forwarded frames from upstreamstation, multicast/broadcast frames and transmitted frame from the localstation. If there are several frames to be sent within a node at thesame time, the schedule unit will decide which frame will delivery firstto the downstream along the ring.

5.3.8 RPR Rx Framer: a RPR MAC framer in Rx side, it terminates a frameof IEEE 802.17 through a station via the ringlet.

5.3.9 RPR Tx Framer: a RPR MAC framer in Tx side, it terminates a frameof IEEE 802.17 through a station via the ringlet.

5.3.10 Flow Rx Framer: an abstract of physical framer of Flow at Rxside, it stands for a framer of TCE, Frame Relay or Ethernet framer.

5.3.11 Flow Tx Framer: an abstract of physical framer of Flow at Txside, it stands for a framer of TCE, Frame Relay or Ethernet framer.

5.3.12 XP Rx Processor: a set of logical functions (of RPR MAC client)used to XP processing in Rx direction. It includes Rx entity to getpackets from RPR MAC, discrimination of multicast/broadcast based onflow, FT/CS/NM value, FN value, FSN value and other associated XPprotocol processing.

5.3.13 XP Tx Processor: a set of logical functions (of RPR MAC client)used to XP processing in Tx direction. It includes Tx entity outgoing toRPR MAC, Tx schedule unit, functions of determination of NA, TTL,FT/CS/NM, FN and FSN, multicast/broadcast from the view of RPR MAClayer. The other associated XP protocol processing is also included.

5.3.14 Addressing (48 bit OUI): The IEEE 48 bit OUI is generally used asMAC addresses. It contains: Individual/Group bit—identifies unicast andmulticast/broadcast frames, Universal/Local bit—indicates that theaddress was assigned by IEEE and the manufacturer and should be unique,IEEE assigns value of 24 bits, manufacturer assigns remaining 22—localindicates a locally administered address. It is the responsibility ofthe administrator to insure uniqueness. MSF will use universal addressand the broadcast address in support of flow services.

5.4 Reference Point in MAC Client of a Data Node

The four different Reference Points are defined in a node.

5.4.1 Reference Point G1: a reference point between RPR MAC and itsclient. It stands for processing sink of RPR MAC framer in RPR MACclient side.

5.4.2 Reference Point G2: a reference point between RPR MAC and itsclient. It stands for processing source of RPR MAC framer in RPR MACclient side.

5.4.3 Reference Point T1: a reference point between Flow Rx Framer andXP processor. It stands for processing sink of XP before Flow Rx framerof TCE or Ethernet etc.

5.4.4 Reference Point T2: a reference point between Flow Tx Framer andXP processor. It stands for processing source of XP after Flow Tx framerof TCE or Ethernet etc.

5.5 Transport Functional Architecture of MSF Networks

5.5.1 General

The functional architecture of MSF transport networks is described usingthe generic rules defined in Patent G.805. The specific aspectsregarding the characteristic information, client/server associations,the topology, the connection supervision and multipoint capabilities ofMSF transport networks are provided in this Patent.

In a MSF network two levels of multiplexing are used. A node-levelmultiplexing is used to trunk multiple packet flows in a single networkelement. A unique tag (flow number) is used to distinguish betweenclient flows/connections. A ring level MAC layer is used to multiplextrunks from multiple nodes on a shared ring.

MSF is defined in a modular way; hence a variety of MAC protocols canserve the XP layer. RPR could be one realization of the MAC layer. Inthat case the Destination MAC address field is used to perform themultiplexing function.

5.5.2 MSF Layer Networks

Two layer networks are defined in the MSF transport networkarchitecture:

-   -   XP Layer Network.    -   MAC/Data-Link Layer (MDL) Network. The MDL layer could be either        connection-oriented or connectionless.

The XP layer network is a path layer network. The MDL layer network is asection layer network. A MSF packet consists of payload, XP header andMDL header.

5.5.2.1 XP Layer Network

The XP layer network provides the transport of adapted informationthrough a XP trail between XP access points. The adapted information isa non-continuous flow client frames (the minimum and maximum frame sizeis protocol dependent). The XP layer network characteristic informationis a non-continuous flow of adapted information extended with XP header(see 5.5.2.1.2), and CS or NM packets. The XP layer network contains thefollowing transport processing functions and transport entities:

-   -   XP trail.    -   XP trail termination source (XPT source): generates CS or NM        packets.    -   XP trail termination sink (XPT sink): terminates CS or NM        packets.    -   XP network connection (XPNC).    -   XP link connection (XPLC).    -   XP subnetwork connection (XPSC).        FIG. 3 Shows a XP Layer Network Example.        5.5.2.1.1 XP Trail Termination

The XP trail termination source accepts adapted information at itsinput, add the flow traffic, inserts CS or NM packets and presents thecharacteristic information of the XP layer network at its output. The XPtrail termination source can be used without binding its input to anadaptation function, e.g. for testing purposes.

The XP trail termination sink accepts the characteristic information ofthe XP layer network at its input, terminates the flow traffic, extractsthe CS or NM packets and presents the adapted information at its output.

The XP trail termination (XPT) consists of a co-located XP trailtermination source and sink pair.

5.5.2.1.2 XP Header Format

Please refer to section 7.

5.5.2.2 MDL Layer Network

The MDL layer network provides the transport of adapted informationthrough an MDL trail between access points. The adapted information is anon-continuous flow of XP layer network characteristic information plusthe flow number. The MDL layer network characteristic information is anon-continuous flow of adapted information and OAM information. The MDLlayer network contains the following transport processing functions andtransport entities (see FIG. 3):

-   -   MDL trail.    -   MDL trail termination source (MDLT source): generates CS or NM        packets.    -   MDL trail termination sink (MDLT sink): terminates CS or NM        packets.    -   MDL network connection/flow (MDLNC/MDLNF).    -   MDL link connection/flow (MDLLC/MDLLF).    -   MDL subnetwork connection/flow (MDLSC/MDLSF).        FIG. 4 Shows a MDL Layer Network Example (Connection-Oriented        (Upper)/Connectionless (Bottom)).        5.5.2.2.1 MDL Trail Termination

The MDL trail termination source accepts adapted information at itsinput, inserts CS or NM packets and presents the characteristicinformation of the MDL layer network at its output. The MDL trailtermination source can be used without binding its input to anadaptation function, e.g. for testing purposes.

The MDL trail termination sink accepts the characteristic information ofthe MDL layer network at its input, removes the CS or NM packets andpresents the adapted information at its output.

The MDL trail termination (MDLT) consists of a co-located MDL trailtermination source and sink pair.

5.5.3 Client/Server Associations

A key feature of the MSF transport assembly provides the informationtransfer capability required to support various types of services ofdifferent bit rates by various server layers.

In terms of client/server associations, the MSF transport assemblyoffers a XP trail and uses a trail in a server layer network. This isillustrated in FIG. 5.

FIG. 5 Shows a Client/Server Association in a MSF Transport Ring.

5.5.3.1 XP/Client Adaptation

The XP/Client adaptation is considered to consist of two types ofprocesses: client-specific processes and server-specific processes.

Client-specific processes includes

-   -   Detection of client defects. Two generic types of defects are        -   Loss of Client Signal        -   Loss of Client Synchronization

Service-specific XP/Client adaptation source performs the followingfunctions between its input and its output:

-   -   Adding XP header.

Service-specific XP/Client adaptation sink performs the followingfunctions between its input and its output:

-   -   Remove XP header.

The bi-directional XP/Client adaptation function is performed by aco-located pair of source and sink XP/Client adaptation functions.

5.5.3.2 MDL/XP Adaptation

The MDL/XP adaptation source performs the following functions betweenits input and its output:

-   -   Packet multiplexing,    -   Adding MDL header.

The MDL/XP adaptation sink performs the following functions between itsinput and its output:

-   -   Packet demultiplexing according to flow number value,    -   MDL header extraction.

The MDL/XP adaptation consists of a co-located MDL/XP adaptation sourceand sink pair.

5.5.3.3 MDL/Physical Layer Adaptation

Beyond the scope of this Patent.

5.5.4 Topology

MSF supports unicast, half-duplex multicast and broadcast connections.

In half-duplex multicast service, traffic from single source port ismulticasted to several sink ports.

5.5.4.1 Multipoint Connection Point (MPCP)

The MPCP is a reference point that binds CP or a set of CPs.

FIG. 6A Shows XP Layer Multipoint Connection Points Examples.

5.5.4.2 Point-to-Multipoint Connections

A point-to-multipoint MDL Network Connection/Flow multicasts customertraffic from single node to a group of nodes. A point-to-multipoint XPNetwork Connection multicasts customer traffic within a single node,from an MDL/XP adaptation sink to multiple XP/Server adaptation sinks.

FIG. 6B Shows a Flow Based 1+1 Protection.

5.6 Operation of Network Management Frames in MAC Client

5.6.1 Initial Configuration Table (ICT) Operation

ICT is a mapping table reflecting the initial and available value of FTand FN within a node and TCCR between nodes along a ringlet duringengineering installation. The ICT must be pre-installed before MSFengineering operation. The incorrect ICT will lead to fault of Flowservices on a ring. CT_Request frame with an ICT parameter reflectinginitial TCCR of all nodes on a ring is sent to other nodes bybroadcast/multicast mode from a node (called Node A, e.g. Centralstation in the most case) by network management interface during initialengineering operation period. All nodes (called Node B) receivedCT_Request frame will build corresponding mapping relations of TCCR inthe local node and give a point-to-point response by CT_Response frameto Node A.

All nodes on a ring will wait to be assigned ICT during engineeringinstallation period. After issuing CT_Request frame, Node A willautomatically send CT_Request frame again after retransmit timer (it isprogrammable, named for Timer_ct) if Node A does not receivecorresponding CT_Response frame. It is believed that Node B is notreachable after N_ct times of retransmission (N_ct is programmablealso).

If Node A has received a message of CT_Response frame with a Nullparameter from Node B either before CT retransmit expired or before N_cttimes of retransmission, it is believed that ICT operation for Node B issuccessful.

5.6.2 Configuration Updating Table (CUT) Operation

CUT is a mapping table reflecting the available value modification of FTand FN in a node and TCCR between nodes on the MSF ring during anon-line operation. The incorrect CUT will lead to fault of Flow on MSFring. CT_Request frame with a CUT parameter reflecting changed part ofTCCR of all nodes on MSF ring is sent to other nodes (called one of themNode B) by broadcast/multicast mode from a node (called Node A, e.g.Central station in the most case) by network management interface duringnormal engineering operation period. All nodes received CT_Request framewill build corresponding mapping relations of TCCR in the local node andgive a point-to-point response by CT_Response frame to Node A.

After issuing CT_Request frame, Node A will automatically sendCT_Request frame again after retransmit timer (it is programmable, namedfor Timer_Ct) if Node A does not receive corresponding CT_Responseframe. It is believed that Node B is not reachable after N_ct times ofretransmission (N_ct is programmable also).

If Node A has received a message of CT_Response frame with a Nullparameter from Node B either before retransmitted CT expired or beforeN_ct times of retransmission, it is believed that CUT operation for NodeB is successful.

5.6.3 Configuration Table Inquiry (CTI) Operation

CT_Request frame with a Null parameter is sent to other nodes (calledone of them as Node B) by unicast/multicast/broadcast mode from a node(called Node A, e.g. Central station in the most case) by networkmanagement interface during normal engineering operation period. Allnodes received CT_Request frame with a Null parameter will send apoint-to-point response by CT_Response frame with a CTI parameterreflecting actual configuration table of the local node on a ring toNode A.

5.7 Fault Management in MAC Client

If a fault occurs, Fault_Report frame with a fault parameter is sent todesignated node (connected to network management interface). The networkmanagement entity can pass Fault_Request Frame with a fault parameterfrom designated node to a targeted node. The targeted node issuesFault_Response Frame with a fault parameter defined to designated nodeas a responding.

5.8 Performance Management in MAC Client

Once 15 minutes or 24 hours expired, each node in a ring will issuePerformance_Report frame with a performance parameter defined in 7.10.1to designated node (connected to network management interface). Thenetwork management entity can pass Performance_Request Frame with aperformance parameter from designated node to a targeted node if neededanytime. The targeted node responds by Performance_Response Frame with aperformance parameter to designated node.

6 The Framework

6.1 The Protocol Framework of Trunk Pipe

The protocol framework of XP is shown as FIG. 7. This Patent treats XPas an upper layer protocol of 802.17 MAC. The use of control signals isnot required. The self-synchronous scrambling/descrambling function isnot applied in XP layer during insertion/extraction into/from the MACpayload of RPR. Communication service facilities between XP and RPR MAClayer are accomplished by means of primitives (MA_DATA request andMA_DATA indication, MA_Control request and MA_Control indication shownin FIG. 8) with parameters of Ring Control Field, Destination MACAddress, Source MAC Address, Protocol Type filed, topology status,FT/CS/NM, FN value, FSN and payload or parameters of XP layer, as shownin section 7. Specification of Primitives specifies the interactionbetween XP and MAC layer to invoke and provide a service, and presentsthe elements of primitives.

XP located at RPR MAC client is the data link protocol also, whichprovides point-to-point transferring over RPR MAC frame. Theestablishment and disconnection of flow service are accomplished by theassociated control signalling (Oust like Soft Permanent Virtual Circuit)or network management frames. Communications between data link and theassociated upper protocols are accomplished by means of primitivesaccording to the principle of ITU-T Patent X.212.

The service facility of X) provided to its upper protocols via SAP(Service Access Point) is the XP-UNACK-DATA request primitive with “Userdata” (data frame in Flow and frame of CS/NM) and “Priority” parameterset in a node, and the XP-UNACK-DATA indication primitive with “Userdata” (data frame in Flow and frame of CS/NM) and “Priority” parameterfrom received frame. “User data” is the outgoing/incoming upper layerpacket. The default maximum frame size of XP shall be aligned to thesize that RPR does after taking into account the overhead of XP frame.Supporting the maximum frame size of Ipv6 jumbo payload needs to alignwith IEEE 802.17. The octet stuffing procedure will not be used in thiscase.

An invalid frame is a frame which:

-   -   a) Has fewer than eight octets (includes PT, PFI, 4-bit reserved        field, FT/CS/NM, FN, 4-bit reserved field, FSN fields, HEC        field) within the RPR MAC payload; or    -   b) Contains a FT or FN that is mismatched or not supported by        the receiver.

Invalid frame shall be discarded without notification to the sender. Butfor the lost or duplicated frames of a flow, the results of performancemonitoring should be reported to layer management entity of RPR MACclient and be operated according to 7.10.1.

The connection management entity is used to monitor the XP link statusof receiving the peer link frame. It is local matter only and has notany associated frame to be used between the two sides.

-   -   After initialization (the defaults of T200 and N200 are set to        10 milliseconds and 3 respectively), the XP entity enters the        normal way of transmitter and receiver.    -   If the timer T200 expires before any frames (including MAC data        and control frames) are received at the reference point G1, or        status report from RPR MAC layer by MA_Control Indication or        MA_Data Indication occurs with one or more opcodes, the XP        entity shall restart timer T200 and decrement the retransmission        counter N200.    -   If timer T200 expires and retransmission counter N200 has been        decremented to zero before any frame is received at the        reference point G1, or status report from RPR MAC layer by        MA_Control Indication or MA_Data Indication occurs with one or        more opcodes, the XP entity shall (a) indicate this to the local        connection management entity by means of the LMXP-ERROR        indication primitive, (b) indicate a notification to the local        EFBP/TFBP Function Unit within the node by means of the        EVENT_Report primitive with the FT and FN parameters, and (c)        restart timer T200 and recover the value of N200.    -   The value of T200 and N200 shall be configurable. The minimum        unit configured of T200 and N200 is 5 milliseconds and 1        respectively.        FIG. 7 Shows a Generic Protocol Stack of MSF Based on RPR.        FIG. 8 Shows a Relationship Between XP and RPR MAC, Upper Layer        and XP.        6.2 MSR (Client) Interface to RPR MAC

Four service primitives are defined for the non-bridge clientinterfaces, as shown in section 5.4 (MAC services to the client layer)of IEEE 802.17

-   -   MA_DATA.request    -   MA_DATA.indication    -   MA_CONTROL.request    -   MA_CONTROL.indication

Plus MA_UNITDATA.request and MA_UNITDATA.indication primitives.

6.2.1 MA_DATA Request

This primitive defines the transfer of data from a XP entity to a singlepeer entity, or to multiple peer entities in the case of groupaddresses. The semantics of the primitives are as follows: — MA_DATArequest { destination_address, source_address, [optional]mac_service_data_unit, frame_check_sequence, [optional] service_class,ringlet_id, [optional] mac_protection, [optional] mark_fe, [optional]strict_order, [optional] extended_frame, [optional]destination_address_extended, [optional] source_address_extended,[optional] flooding_form [optional])

The parameters of the MA_DATA.request are described in sub-clause5.3.1.2 of IEEE 802.17. This primitive is invoked by XP entity wheneverdata is to be transferred to a peer entity or entities. The receipt ofthis primitive shall cause the MAC entity to insert all MAC specificfields, and any fields that are unique to the particular medium accessmethod, and pass the properly formed frame to the lower protocol layersfor transfer to the peer MAC sublayer entity or entities. The MAC doesnot reflect frames back to the XP. If a client issues a MA_DATA.requestprimitive with a DA value equal to its local MAC address, the request isrejected.

6.2.2 MA_DATA Indication

This primitive defines the transfer of data from the MAC sublayer entityto XP entity. The semantics of the primitive are as follows: — MA_DATAindication { destination_address, source_address, mac_service_data_unit,frame_check_sequence, reception_status, service_class, ringlet_id,fairness_eligible, strict_order, extended_framedestination_address_extended, source_address_extended)

The parameters of the MA_DATA.request are described sub-clause 5.4 ofIEEE802.17. The MA_DATA.indication is passed from the MAC sublayerentity (through the MAC Control sub-layer) to XP entity or entities toindicate the arrival of a frame to the local MAC sublayer entity that isdestined for XP. Such frames are reported only if they are validlyformed, and their destination address designates the local MAC entity(local station address, broadcast or multicast). A XP may elect toaccept or discard frames with FCS errors. The effect of receipt of thisprimitive by XP is unspecified. The MAC does not reflect frames back toXP. If a MAC receives a frame with a SA value of the local MAC address,it does not cause a MA_DATA.indicate primitive to be sent to theoriginating client (XP). This primitive defines the transfer of controlrequests from the XP to the MAC Control sublayer. Its purpose is toallow the XP to control the local MAC. This primitive does not provide adirect means for a XP to transmit a control frame from the local MAConto any ringlet; although control frames (for example echo or flush)may be indirectly generated as a result of this request.

6.23 MA_Control Request

This primitive defines the transfer of control requests from the XPlayer to the MAC Control sublayer. Its purpose is to allow the XP tocontrol the local MAC. This primitive does not provide a direct meansfor a XP to transmit a control frame from the local MAC onto anyringlet; although control frames (for example echo or flush) may beindirectly generated as a result of this request. This primitive definesthe transfer of control commands from a XP entity to the local MACControl sublayer entity. The semantics of the primitive are as follows:

-   -   MA_CONTROL request {opcode, request-operand-list}

The opcode parameter indicates the control operation requested by the XPentity. OAM_ECHO_REQ opcode with Operand (echo request parameters)(specified in sub-clause 12.3.1 of IEEE 802.17) is used to indicate“Request to transmit an echo request frame”. OAM_FLUSH_REQ opcode withOperand (flush parameters) (specified in sub-clause 12.3.3 of IEEE802.17) is used to indicate “Request to transmit an flush frame”. Thisprimitive is generated by a XP whenever it wishes to use the services ofthe MAC control sublayer entity. The effect of receipt of this primitiveby the MAC control sublayer is opcode-specific.

6.2.4 MA_Control Indication

This primitive defines the transfer of control status indications fromthe MAC control sublayer to the XP. The semantics of the primitive areas follows:

-   -   MA-CONTROL indication {opcode, indication_operand_list}

The elements of the indication_operand_list parameter are specific toeach opcode parameter, and defined in Table 5.3. TABLE 5.3 Opcodes ofMA_Control Indication Specified in Opcode name Meaning OperandsIEEE802.17 OAM_ECHO_IND Receipt of an echo reply frame echo payload andparameters 12.3.1 OAM_FLUSH_IND Receipt of a flush frame flush payloadand parameters 12.3.3 TOPO_CHANGE Topology change topology and statusdatabase 10.2.6 PROT_CHANGE Protection change topology and statusdatabase 10.2.6 SEND A send A change true/false, ringletID 6.6.1 SEND Bsend B change True/false, ringletID 6.6.1 SEND C send C changeHopsToCongestion, ringletID 6.6.1 SC_FCM_IND Receipt.of SC-FCMallowedRate, allowedRateCongested, 9.6 hopsToCongestion, ringletIDMC_FCM_IND Receipt of MC-FCM fairnessMessageType, controlValue, 9.6sourceAddress, TTL, ringletID

The MA_CONTROL.indication is generated by the MAC control sublayer underconditions specific to each MAC control operation. The effect of receiptof this primitive by the XP is undefined. The usage of these indicationsby the XP is beyond the scope of this standard; however they are madeavailable to allow a XP to perform more complex actions beyond thecapability of the MAC, for example, implementing a more efficient framescheduling algorithm based on the knowledge of choke points reported viathe SC_FCM_IND.

6.2.5 RPR MAC Interface to the Bridge Client

RPR MAC internal sub-layer service (ISS) is provided by a MAC entity tocommunicate with the MAC relay entity if flow services of MSF needs tobridge to another MSF. The interface for this sublayer is predefined inIEEE Std 802.1D-1998 and IEEE Std 802.1Q-1998. The MSF will use thesespecifications. The bridging operation of Flow traffic depends on theability to flood frames. The unidirectional flooding via either ringlet0or ringlet1 is applied to send the frame to all other stations in thering.

6.2.5.1 Primitives and Parameters Involved in Internal Sub-Layer Service

On receipt of a MA_UNITDATA.request primitive from XP layer, the localMAC entity performs data encapsulation to form a MAC frame using thefollowing parameters and default setting. On receipt of a MAC frame froman trunk pipe, the frame is passed to the reconciliation sub-layer whichdisassembles the MAC frame into parameters, as specified below, that aresupplied with the MA_UNITDATA.indication primitive to XP layer. Theparameters of the primitive are as follows:

-   -   frame_type parameter takes only the value user_data_frame and        shall be encoded in the FT field of the header field.    -   mac_action parameter takes only the value        request_with_no_response and is not explicitly encoded in MAC        frames.    -   destination_address parameter is either the address of an        individual MAC entity (end station) or a group of MAC entities.        Destination_address parameter is the MAC address of the intended        destination entity, independent of whether the entity is local        or non-local (bridged) to the ring.    -   source_address parameter is the individual address of the source        MAC entity (end station). The source_address parameter is the        MAC address of the originating entity, independent of whether        the source entity is local or non-local (bridged) to the ring.    -   RIF parameter is the routing information field parameter        specified by the 802.1Q EISS. It is passed transparently by the        RPR MAC.    -   mac_service_data_unit parameter is the service user data and        shall be encoded in the data field.    -   user_priority parameter provided in a data request primitive        shall be encoded in the service class bits of the RPR control        field of the MAC frame in accordance with user priority request        and MAC service class. The user_priority parameter provided in        the data indication primitive takes the value of the service        class bits of the RPR control field of the MAC frame in        accordance with the user priority indication and MAC service        class.    -   access_priority parameter in an MA_UNITDATA.request primitive is        mapped to the service class bits of the RPR control field of the        MAC frame in accordance with the access priority request and MAC        service class. The mapping of user_priority to outbound        access_priority is achieved via fixed, MAC method-specific        mappings. The access_priority parameter in a MA_UNITDATA.request        primitive (6.4 of 802.1D) shall be determined from the        user_priority.    -   ringletID parameter is an optional request parameter selecting        the ringlet on which the frame is to be transmitted. If the        ringletID parameter is omitted, the MAC shall use its default        algorithm to determine which ringlet to use. The ringletID        parameter is encoded in the MAC frame. The ringletID parameter        is also provided in the indication primitive indicating which        ringlet the frame was received. The ringletID receive parameter        may be ignored by the MAC client.    -   MACProtection parameter is an optional request parameter        requesting protection service for the transmitted frame. If the        MACProtection parameter is omitted, the MAC shall provide        protection for the frame.    -   markFE parameter is an optional request parameter requesting        class B priority frames to be treated as fairness eligible. If        the markFE parameter is omitted, the MAC shall apply default        frame handling.    -   receptionStatus parameter is an optional indication parameter        providing MAC frame reception status to the MAC client entity.        The receptionStatus parameter may be ignored by the MAC client.    -   fairnessEligible parameter is an optional indication parameter        indicating the setting of the faimesseligible bit in the frame        header. The fairnessEligible parameter may be ignored by the MAC        client.    -   frame_check_sequence parameter is encoded in the FCS field of        the MAC frame. The FCS is computed as a 32-bit CRC beginning        with the first octet following the header checksum to the end of        the frame. A bridge may choose to transmit strict or relaxed        mode frames using this format. These frames may be received by        either a host or a bridge giving rise to the        MA-UNITDATA.indication primitive.        6.2.6 MAC Shapers Supplied to the XP

The shapers and indications to the XP operate based on a per-ringlet.The behaviours of all shapers can be characterized by a common algorithmwith instance-specific parameters. All shapers' credits are adjusteddown or up by decSize and incSize respectively. The decSize and incSizevalues typically represent sizes of a transmitted frame and of creditincrements in each update interval respectively. Crossing below theloLimit threshold will generate a rate-limiting indication, so thatoffered traffic can stop before reaching zero credits, where excessivetransmissions are rejected. The hiLimit threshold limits the positivecredits, to avoid overflow. When frames are ready for transmission,credits can accumulate to no more than hiLimit.

Optional idle frames from the MAC rate synchronization are shaped byshaperi (shaper of idles). Frames from the MAC control usually shaped byshaperM (shaper of MAC). Those control frames directed to the class B orclass C add paths, are shaped by the shapers for those add paths. Allclass A add traffic is shaped by shaperA, to avoid having the XP exceedits class A allocated rates. shaperA is logically partitioned intoshaperA0, shaperA1, and shaperM. MAC control and XP traffic both flowthrough shaperA. All class B add traffic is shaped by shaperB and/or byshaperC, to constrain the XP within its class B rates. All class C addtraffic is shaped by shaperC, to constrain the XP within its weightedfair-share use of the unused and reclaimable bandwidth.

Each MAC rate shaper can be readily identified by its credit-value name.Some of the transmission paths are affected by only one of theseshapers; others are influenced by multiple shapers. The detailedoperations and descriptions are referred to as sub-clause 6.7 of IEEE802.17.

6.2.7 Choice of Strict and Relaxed Transmissions

Two types of frame transmission are supported, relaxed and strict to XPat client level. If the strict mode is applied by the RPR MAC,duplication of user data frames and reordering of frames are notpermitted. The complexity of supporting strict transmission isparticularly burdensome during station or link failures, or ringletselection. So MSF uses relaxed as a default mode with a minimal amountof reorder and/or duplication. If application is required to providestrict transmission, the mode switch will be made using an opcode ofstrictOrder carried by the related primitives.

6.2.8 Topology Database Interface to MSF

MSF uses topology database from RPR MAC in the case of two-fibre ringapplication and chain. These topology messages contain information aboutthe originating station, and the configuration and capabilities makingup the current topology image of that station. These messages aregenerated on initial start of topology discovery periodically and ondetection of a change in station or ring status. The topology imagerepresents (1) a loop of stations or (2) a chain of stations resultingfrom a ring broken at one or more points. LME image of the topology isapplied to do this function using the related MIB and primitive, i.e.

-   -   MLME-REQUEST.get    -   MLME-REQUEST.set    -   MLME-INDICATE.event    -   MLME-RESET.request    -   MLME-RESET.confire

A description will be added to D2.2 on how the LME is used in support ofhigher layer clients.

6.3 Flow Adaptation Function Unit

Flow Adaptation Function Unit is an adaptation function from/to variousindependent flow type signals to/from reference point T1/T2. It has FlowAdaptation Source Function and Sink Function. The Sink corresponds toreference point T1, The Source to reference point T2. This adaptationfunction includes the signal and rate transform, synchronous functionbetween Flow Rx/Tx Framer and flow service interface.

7 Generic Frame Format

A XP frame uses a fixed sized header. The generic frame format is shownin FIG. 9. All binary fields in the following descriptions aretransmitted in Most Significant Bit (MSB) to Least Significant Bit (LSB)order, from top to bottom. The definitions of Ring Control Field,Destination Address, Source Address, Protocol Type Field, HeaderChecksum and FCS Field have been specified in IEEE 802.17 RPR. Thissection will focus on the FT, PFI, 4-bit reserved field, FT/CS/NM, FN,4-bit reserved field, FSN field. Protocol type field is 0x88 bc assignedby IEEE. The above format is only one example. The arrangement of thefields could be changed by adding/deleting some fields or changing thesequence of the fields according to the present invention.

FIG. 9 Shows a Generic Frame Format.

7.1 Destination Address for Use of This Patent

MSF does support for both local address and OuI MAC addresses, so this48-bit field is an OUI MAC address or local address. It is required thatall nodes of the same topology use the unified address, either OUI MACaddress or local address. The nodes with a local address (includingPLAS) shall communicate each other within the scope of a said topology.The bridging and floodingForm shall not be used. If OUI MAC address isapplied, IEEE assigns value of 24 bits, manufacturer assigns remaining22—local indicates a locally administered address. It is theresponsibility of the administrator to insure uniqueness.

The Individual/Group (I/G) address bit (LSB of octet 0) is provided toidentify the destination address as an individual address or a groupaddress. If the I/G address bit is “0”, it indicates that the addressfield contains an individual address. If this bit is “1”, the addressfield contains a group address that identifies one or more (or all)stations connected to the ringlet or other topologies. The all-stationsbroadcast address is a special, predefined group address of all 1's.

The Universally or Locally administered (U/L) address bit is the bit ofoctet 0 adjacent to the I/G address bit. This bit indicates if theaddress has been assigned by a local or universal administrator.Universally administered addresses have this bit set to “0”. If this bitis set to “1”, the entire address (i.e., 48 bits) has been locallyadministered.

In the case of I/G address bit is used to Individual and U/L address bitis used to Local application, and all other bits of Octet 1 and Octet 0of 48-bit address field are set to all “0”, this Patent defines a 32-bitPure Local Address Structure (PLAS). The PLAS is an address of Node Linkon the MSF ring. NA is a local address and has local meaning only alongthe MSF ring. It contains 4 octets (Octet 2, 3, 4, 5). Each bit (binary“0” or “1”) corresponds to a node. For example, LSB of Octet 2 throughMSB of Octet 5, the binary “00100000 00000000 00000000 00000000” standsfor the 3^(rd) Node Address (station), the binary “00000100 0000000000000000 00000000” stands for the 6^(th) Node Address (station) (referto FIG. 1). You may also use binary “00000010 00000000 0000000000000000” to stand for 7^(th) Node Address of new insertion and theactual number location of the 7^(th) Node Address may be corresponded tomiddle position between Node 1 and Node 2 shown in FIG. 1 since the MSFsupports online node insertion. All Node Address must be leftwardalignment and be pre-installed by (NVROM) before engineering operation.The maximum node number of the MSF Ring is 32 in the case of PLAS. Forimplementation, people can use Ethernet MAC and Ipv4/Ipv6 address toperform external network management and identify a node from the networkmanagement level.

7.2 Extended Protocol Field

This 16-bit field is an extended protocol type field of Ethertype fieldnumber #88bc from the IEEE within the new specification to handledifferent aspects of the application and future upgrades over RPR MAC,0x0001: Multiple services flow based on RPR, other value: reserved.

7.3 Payload Type (PT) Field

This 3-bit field is used to indicate a type of XP frame, 0: User Data,1: User Control, 2: Control Signalling (CS), 3: Network Management (NM),4-7: reserved.

7.4 Payload FCS Indicator (PFI) Field

This 1-bit field is used to indicate if the payload FCS of 4 octetspresents, 0: not present, 1: present.

7.5 Reserved Field

This 4-bit field is reserved for future use.

7.6 FT/CS/NM Field

This 8-bit field is used for codes of FT (Flow Type, or User Data), CSor NM. Which type is presented will be dependent on PT field indication.

7.6.1 Flow Type (FT) Field

When PT=binary “000”, this 8-bit field is used to indicate a type of anindependent adding/dropping flow channel to/from the MSF data nodes.Flow channel can be Ethernet or various TCEs. Its codes are as follows(see Table 3). TABLE 3 FT Codes Flow types Code Reserved00000000-00001000 G.702 PDH circuit - Synchronous circuit transport00001001 G.702 PDH circuit - Asynchronous circuit 1.544 Mbit/s 00001010G.702 PDH circuit - Asynchronous circuit 2.048 Mbit/s 00001011 G.702 PDHcircuit - Asynchronous circuit 6.312 Mbit/s 00001100 G.702 PDH circuit -Asynchronous circuit 8.448 Mbit/s 00001101 G.702 PDH circuit -Asynchronous circuit 34.368 Mbit/s 00001110 G.702 PDH circuit -Asynchronous circuit 44.736 Mbit/s 00001111 G.702 PDH circuit -Synchronous circuit 1.544 Mbit/s 00010000 G.702 PDH circuit -Synchronous circuit 2.048 Mbit/s 00010001 G.702 PDH circuit -Synchronous circuit 6.312 Mbit/s 00010010 G.702 PDH circuit -Synchronous circuit 8.448 Mbit/s 00010011 G.702 PDH circuit -Synchronous circuit 34.368 Mbit/s 00010100 G.702 PDH circuit -Synchronous circuit 44.736 Mbit/s 00010101 Reserved for other PDH or DSLspecification 00010110-00010111 Video signal - Distributive televisionservices 00011000 Video signal - Conversational services of bit rateshigher than primary 00011001 rates Video signal - Conversationalservices of p × 64 kbit/s 00011010 signals Reserved for other Videosignals 00011011-00011111 Voiceband signal - 64 kbit/s A-law codedPatent G.711 signals 00100000 Voiceband signal - 64 kbit/s μ-law codedPatent G.711 signals 00100001 Reserved for other- Voiceband signals00100010-100111 Digital channel supported by 64 kbit/s-based ISDN -Transport of 00101000 64 kbit/s channel Digital channel supported by 64kbit/s-based ISDN - 00101001 Transport of 384, 1536 or 1920 kbit/schannel Reserved for other TCEs 00101010-00101000 Ethernet (10/100 Mb/s,specified in IEEE802.3) 00110100 GE (specified in IEEE802.3) 00110101Reserved 00110110-11111111Note:The operation of user data between MAC and client will be implemented byinvoking MA_Data Request and return of MA_Data Indication defined insection 5.4 of IEEE 802.17.7.6.2 CS Field

When PT=binary “010”, this 8-bit field is used to identify the types ofcontrol signalling shown in Table 4. The FN and FSN fields are not usedand set to all-zeros value in this case. TABLE 4 Type of ControlSignalling CS Frame Types Code Reserved 00000000-00000100SYNCHRONIZATION Request (Note1) 00000101 SYNCHRONIZATION Indication(Note1) 00000110 Topology Discovery Request (implemented by 00000111 RPRMAC, via MA_Control Request) (Note2) Topology Discovery Indication(implemented by 00001000 RPR MAC, via MA_Control Indication) (Note2)Reserved 00001001-11111111Note 1:It is optional timing (sync.) method for TCE flow, the method (d) is thefirst option in sub-clause 9.5.2.Note 2:Operation of Control frame between MAC and client will be implementedvia MA_Control Request and Indication defined in section 5.4 of IEEE802.17.Note 3:the other codes of Flow based protection, multicast, bandwidth policing,security and rate duplication is also shown in section 10.7.6.3 NM Field

When PT=binary “011”, this 8-bit field is used to identify the types ofnetwork management frame (OAM) shown in Table 5. The FSN and FN fieldsare not used and set to binary all-zeros value in this case. TABLE 5Type of Network Management Frame (OAM frame) NM Frame Types CodeReserved 00000000-00000110 CT_Request Frame 00000111 CT_Response Frame00001000 Fault_Report Frame 00001001 Fault_Inquiry_Request Frame00001010 Fault_Inquiry_Response Frame 00001011 Performance_Report Frame00001100 Performance_Inquiry_Request frame 00001101Performance_Inquiry_Response frame 00001110 LMXP_ERROR_IndicationRequest frame 00001111 TRL request frame 00010000 TRL response frame00010001 TRL shortcut request frame 00010010 TRL shortcut response frame00010011 NRV request frame 00010100 NRV response frame 00010101 NRVshortcut request frame 00010110 NRV shortcut response frame 00010111Reserved 00011000-111111117.7 Flow Number (FN) Field

This 20-bit field is a number of same type of Flow Ports within a MSFdata node.

7.8 Reserved Field

This 4-bit field is reserved for future use.

7.9 Frame Sequence Number (FSN) Field

This 8-bit field is used to identify Frame Sequence Number (FSN) ofEthernet or TCE data frames or in numbered modulo N_fsn=64 (defaultvalue, N_fsn is programmable and can be configured to 256 if applicationneeds) from 0 to 63. The field is used to performance monitoringfunction for packet lost or duplicated of TCE based flow. The relatedoperation is given in section 9.3. The FSN field will be set to all-zerovalue if the signalling control frames or network management frames arepresented.

7.9.1 Processing in the Transmit Side

The XP provides a sequence count value and a XP indication associatedwith each frame in the transmit side. The count value applied to FSNfield and starts with 0, it is incremented sequentially to 63 andnumbered modulo is 64 (default value). When the data link framescarrying Flow payloads traverse a MSF topologies, they may arrivedestination station disorderly, or lost or duplicated one or moreframes. Due to this reason, it is required that frames must be deliveredin order.

7.9.2 Processing in the Receive Side

The Data Link entity in the receive side must detect the lost orduplicated frames modulo by modulo, and track the following status ofdynamic data stream:

-   -   Frame sequence number and count;    -   Frame loss (if occur);    -   Frame duplication (if occur).

There are two ways to solve the real-time processing problem, (1) try toreorder and sort into the correct order, or (2) drop those disorderingframes, when disordering case occurred. In implementation, these twomethods should be all supported. If method (1) does not meet reliabilitytransport and performance requirement still, the method (2) will beapplied. Due to the limitation of native speed and acceptable delay ofdata link processing, this Patent does not support correction method forbit errors and frame losses. If the event of any lost or duplicatedframe occurred, data link entity will report to the layer managemententity by LMXP-ERROR Indication (see section 9).

7.10 HIEC Field

The header CRC is a 16-bit checksums. Its generator polynomial is:CRC-16=x⁶+x¹²+x⁵+1. The checksum is computed over the PT, PFI, 4-bitreserved field, FT/CS/NM field, FN, another 4-bit reserved field and FSNfield within the scope of XP, with the bits of the frame presented tothe CRC generator in the same order as is described in IEEE 802.17. Theinitial value for the HEC CRC calculation is an all-zeros value.Single-bit error correction by the receiver is optional.

7.11 Payload of XP

When Flow or Ethernet Packet is applied, payload field is used toencapsulate upper layer protocol data or TDM data listed in Table 3.Payload is octet-oriented and its size is variable. The default maximumframe size shall be aligned to the size that RPR does for bothIPv4-based and IPv6-based applications (the support of jumbo payloadneeds to align with IEEE 802.17 specification). Except for Flow, controlsignalling frame and network management are described below.

7.11.1 Control Signalling and Network Management Part

The XP does work by sending both data frame into a unidirectionalringlet and the associated network management/control frames into acounter-rotating ringlet. Generic format of CS/NM Frames is the same asthat of FIG. 9, just payload field is replaced by the related parametersshown in FIG. 9. The difference of the parameter field indicates variouscontrol signalling and network management frames below. The first octetof parameters field is used to identify how many parameters are used ina CS or NM frame. Each parameter following 1^(st) octet consists of type(or tag), length and value of the parameter. If the total octet numberof parameters field is not based on 4-octet, it is optional that theoctets padding (Binary 00000000) may be used.

7.11.1.1 CT_Request Frame

The code value of CT-Request Frame is binary “00000111”. CT-RequestFrame can be applied to point-to-point operation of Flow based and nodebased, and also used to node based multicast/broadcast operation. Forthe Flow based multicast/broadcast operation, please refer to as section11 of this Patent. The major portion of CT is TCCR ID. A TCCR IDconsists of FNi ID (This is an identifier of Flow p within node x),2-bit U/M/B field (6-bit is reserved and set to binary 000000), 8-bitlength field (This filed is used to indicate the total number of FlowFNj ID following length field) and one or more FNj ID (This is anidentifier of Flow q within node y). ID is a value of identifier, FNi,FNj, FNk and FNm are the ith Flow Number of same FT of Node n, the jthFlow Number of same FT of Node o, the kth Flow Number of same FT of Nodep and the mth Flow Number of same FT of Node q. The values of n, o, p, qare 0 through 31, and stands for numbering of node. The values of i, j,k, l are 0 through 2²⁰-1, and stands for flow number with the same FTvalue. In the case of node based broadcast mode, the expressive schemeis very simple and just one FNi ID is used only. It will be sent toreach all stations.

FIG. 10 Shows Expressions of FN ID and TCCR ID.

Note: FNi ID=NAx(x=1,2,3 . . . 256)+FT+FNp (p=0,1,2,3, . . . 2²⁰-1), toidentify the path Flow with the fixed FT and FN value within ith node.For the case of Multicast/Broadcast Mode, a flow based outgoing packetwithin a source node can be multicast or broadcast to a designated orsource flow (ST) of other sink nodes along a MSF ring or othertopologies. Each sink node should have only a source flow to receivethis packet from ringlet at a time. If a membership group of multicastor broadcast has been established within a sink node, the said ST willduplicate this packet to other flows with the same membership relation.

What the ICT, CUT and Null parameters indicate is three differentoperations: ICT, CUT and CTI. Its type and field are described below inTable 6. TABLE 6 Parameter Type of CT_Request Frame Parameter typeParameter Field ICT Binary “00000001 00100000 + “octet number ofparameter” + “value of TCCR ID shown in FIG. 10” CUT Binary “0000000100100001 + “octet number of parameter” + “value of TCCR ID shown in FIG.10” Null Binary “00000001 00100011 00000001 00000000”Note:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.7.11.1.2 CT_Response Frame

Null parameter in CT_Response Frame is used by ICT and CUT operations.CTI parameter is followed by CTI operation. TABLE 7 Parameter Type ofCT_Request Frame Parameter type Parameter Field CTI Binary “0000000100100100 + “octet number of parameter” + “value of TCCR ID shown in FIG.10” Null Binary “00000001 00100011 00000001 00000000”Note:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.6 and parameter is shownin Table 7.

7.10.1.3 Fault_Report Frame TABLE 8 Parameter Type of Fault_Report FrameParameter type Parameter Field PSF Binary “00000001 00000011 0000000100000000” PSD Binary “00000001 00000010 00000001 00000000”Note:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.7 and parameter is shownin Table 8.

7.11.1.4 Parameter of Fault_Inquiry_Request Frame TABLE 9 Parameter Typeof Fault_Inquiry_Request Frame Parameter type Parameter Field NullBinary “00000001 00100011 00000001 00000000”Note:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.7 and parameter is shownin Table 9.

7.11.1.5 Parameter of Fault_Inquiry_Response Frame TABLE 10 ParameterType of Fault_Inquiry_Request Frame Parameter type Parameter Field PSFBinary “00000001 00000011 00000001 00000000” PSD Binary “0000000100000010 00000001 00000000”Note:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.7 and parameter is shownin Table 10.

7.11.1.6 Parameter of Performance_Report Frame TABLE 11 Parameter Typeof Performance_Report Frame Parameter type Parameter Field A set of FNiin a node Binary “00000001 01000000 +” (designated) “octet number ofparameter” + “value of FNi shown in FIG. 10” FNFCS_15m (Total Number ofBinary “00000001 01000001” + FCS error in 15 minutes, “00000100” +“value of 4octets, 4octets length) FNFCS-15m shown in FIG. 10” FNPL_15m(Total Number of Binary “00000001 01000001” + Frame Loss in 15 minutes,“00000100” + “value of 4octets length) FNPL-15m shown in FIG. 10”FNFCS_24h (Total Number of Binary “00000001 01000001” + FCS error in 24hours, 5octets “00000101” + “value of length) “FNFCS-24h shown in FIG.10” FNPL_24h (Total Number of Binary “00000001 01000001” + Frame Loss in24 hours, 5octets “00000101” + “value of length) “FNPL-24h shown in FIG.10”Note 1:FNFCS and FNPL represents two different registers reflected values of“Total Number of FCS error” and “Total Number of Frame Loss”respectively.Note 2:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.8 and parameter is shownin Table 11.

7.11.1.7 Parameter of Performance_Inquiry_Request Frame TABLE 12Parameter Type of Performance_Inquiry_Request Frame Parameter typeParameter Field A set of FNi in a node Binary “00000001 01000000 +“octet number of (designated) parameter” + “value of FNi shown in FIG.10”Note 1:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.8 and parameter is shownin Table 12.

7.11.1.8 Parameter of Performance_Inquiry_Response Frame TABLE 13Parameter Type of Performance_Inquiry_Response Frame Parameter typeParameter Field A set of FNi in a node Binary “00000001 01000000 +”(designated) octet number of parameter” + “value of FNi shown in FIG.10” FNFCS_15m (Total Number of Binary “00000001 01000001” + Frame Lossin 15 minutes, “00000100” + “value of 4octets length) FNFCS-15m shown inFIG. 10” FNPL_15m (Total Number of Binary “00000001 01000001” + FrameLoss in 15 minutes, “00000100” + “value of 4octets length) FNPL-15mshown in FIG. 10” FNFCS_24h (Total Number of Binary “0000000101000001” + Frame Loss in 24 hours, 5octets “00000101” + “value oflength) FNFCS-24h shown in FIG. 10” FNPL_24h (Total Number of Binary“00000001 01000001” + Frame Loss in 24 hours, 5octets “00000101” +“value of length) FNPL-24h shown in FIG. 10”Note 1:FNFCS and FNPL represents two different registers reflected values of“Total Number of FCS error” and “Total Number of Frame Loss”respectively.Note 2:the interface interaction between MAC and client are operated viaMA_Data Request and Indication primitives.

The corresponding operation is got in section 5.8 and the parameters areshown in Table 13.

7.12 XP Payload FCS

The Frame Check Sequence (FCS) is a 32-bit cyclic redundancy check (CRC)as used in IEEE 802.3 CSMA/CD. The generator polynomial is:CRC-32=x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x¹+1

The FCS CRC is calculated starting from the octets following the HECfield to the end of frame, with the bits of the frame presented to theCRC generator in the same order as is described IEEE 802.17. The initialvalue for the FCS CRC calculation is an all-ones value. If Ethernet iscontained in the payload, or CS/NM parameters are contained in thepayload, PFI is set to zero and XP payload FCS will not be used.

8 Flow Loopback (TRL) and Node Reachability Verification (NRV)

8.1 Flow Loopback (FRL)

Once TRL function is set, a node provides local or remote data channelshortcut from Tx interface to Rx interface in Flow. This Patent allowsthe XP entity to get a TRL request (OAM) operation from OAM to aspecific destination in order to check the Flow connectivity of a MSFstation. At the interface from OAM to MAC, parallel operation should bemade by the corresponding MIB in RPR MAC to invoke an OAM framespecified in subclause 12.3.1 of IEEE 802.17. TRL_request used by XP OAMwhen transferred to both RPR MAC and XP entity from OAM will produce aTRL operation. The MSF TRL request (OAM operation) capability allows fora frame to be inserted in a Flow at one station in the ring, and aLoopback response (XP operation) returned by a peer Flow of anotherstation through the same or opposite ringlet, with minimal impact on thedata flow between stations. Those frames activated by TRLrequest/response operation can be assigned any service class. Thoseframes activated by the TPL request may contain any number of userspecific octets up to the maximum permitted frame size, and the userDatais copied into the reply frame. The TRL request/response operation canbe sent through the default ringlet, ringlet0 or ringlet1 for thedual-fibre ring case.

The operation of a TRL request source station from a XP OAM shallcontain:

-   1) The invocation of network management (OAM) frame of MSF-   2) The related fields of network management frame includes:-   a) The DA to the target MAC address-   b) The SA to its own MAC address-   c) The values of target FT and FN, service class of payload-   d) The route of request operation, i.e. ringlet selection-   e) The desired protectionMode-   f) The payload of a MSF request frame includes (in order): source FN    (20-bit), 12-bit reserved field (set to all “0”) and desired    userData (an integer of octet).

On receipt of a TRL network management frame from an trunk pipe, theresponse frame is passed to the reconciliation sublayer whichdisassembles the MAC frame into parameters. The response operation of asink station in the XP entity shall contain:

-   -   a) Exchange DA and SA of incoming frame to form outgoing        response frame    -   b) Exchange the FN values between source and target    -   c) The route of request operation, i.e. ringlet selection    -   d) The desired protectionMode and userData (payload of a MSF        frame)    -   e) The payload of a MSF response frame includes (in order): the        changed FN (20-bit) value, 12-bit reserved field (set to all        “0”) and copy all received userData from the request frame.

The corresponding type code of network management frame operation islisted in Table 5.

8.2 Flow Loopback (TRL) Shortcut

Once TRL shortcut function is set, a node provides round-trip shortcutalong the ringlet from a local station to itself and also including fromthe local Tx to the local Rx of Flow. This Patent allows the XP OAM torequest a TRL shortcut operation to a specific destination in order tocheck the fibre connectivity of a ringlet. At the interface from OAM toMAC, parallel operation should be made by the corresponding MIB in RPRMAC to invoke a flush operation specified in subclause 1.17 of IEEE802.17. A flush has the effect of clearing the selected ringlet ofpreviously sourced Flow traffic. A flush function is expected to be usedwhen changing the ringlet selection algorithm, when revised ringletselection protocols are necessary to access all stations (forsteer-protection) or to improve bandwidth utilization (for wrapprotection). The RPR flush capability may also be used for Flowcontrolled misorder prevention when changing the preferred ringdirection of a given flow or for Flow determination of RTT. This is veryuseful to allocated bandwidth and account management of Flow based.

The corresponding type code of network management frame operation islisted in Table 5.

8.3 Node Reachability Verification (NRV)

To check Node reachability along a ringlet, this Patent allows the XPOAM to request a NRV operation to a specific destination in order tocheck the node reachability. At the interface from OAM to MAC, paralleloperation should be made by the corresponding MIB in RPR MAC to invokean OAM frame specified in subclause 12.3.1 of IEEE 802.17. The NRVrequest capability allows for a frame to be inserted at one station, anda NRV response (XP operation) returned by another station through thesame or opposite ringlet, with minimal impact on the data flow betweenstations. NRV request/response frames can be assigned any service class.The NRV request frame may contain any number of user specific octets upto the maximum permitted frame size, and the userData is copied into thereply frame. The NRV request/response operation can be sent through thedefault ringlet, ringlet0 or ringlet1 for the dual-fibre ring case.

The operation of a NRV request source station from a XP OAM shallcontain:

-   1) The invocation of network management (OAM) frame of MSF-   2) The related fields of network management frame includes:-   a) The DA of target MAC address-   b) The SA to its own MAC address-   c) The values of target FT and FN and service class of payload are    don't care-   d) The route of request operation, i.e. ringlet selection-   e) The desired protectionMode-   f) The payload of a NRV request frame is don't care

On receipt of an NRV network management (request) frame from a trunkpipe, the response frame is passed to the reconciliation sublayer whichdisassembles the MAC frame into parameters. The response operation of asink station in the XP entity shall contain:

-   -   a) Exchange DA and SA of incoming frame to form outgoing        response frame    -   b) Selection of the desired response route, i.e. ringlet        selection    -   c) The desired protectionMode and userData (don't care)

The corresponding type code of network management frame operation islisted in Table 5.

8.4 Node Reachability Verification (NRV) Shortcut

To check Node reachability along a ringlet, this Patent allows the XPOAM to request a NRV shortcut (request) operation to a specificdestination in order to check the node reachability from a local stationto itself. At the interface from OAM to MAC, parallel operation shouldbe made by the corresponding MIB in RPR MAC to invoke flush operationspecified in subclause 1.17 of IEEE 802.17.

The corresponding type code of network management frame operation islisted in Table 5.

9 TDM Circuit Emulation (TCE) Over MSF

9.1 Introduction

This section provides a protocol model along MSF for TDM basedbit-stream or octet-steam over MSF. Each station can have one or moreTCEs as Flow. TCE is operated end-to-end and is originated from thesource station and terminated at the sink station. TCE can be operatedin the way of half-duplex point-to-point, full-duplex point-to-point orhalf-duplex point-to-multipoint.

9.2 Protocol Framework of TDM Circuit Emulation (TCE)

The protocol framework of TCE is involved in the underlying RPR MACtrunk pipe shown in FIG. 11. The functions of encapsulation, real-timetransport of order, detection of disorder and duplication, sorting,error report, primitives and related parameters, and timing synchronousprocessing etc are performed within the XP.

FIG. 11 Shows a TDM Service Channel Over MSF.

9.3 Services Provided by MSF Data Link

9.3.1 Definitions

The layer services provided by MSF Data link to TCE layer are:

-   -   Transfer of service data units with a constant source bit rate        from TCE layer and the delivery of them with the same bit rate        in MSF data link layer; and/or    -   Transfer of timing information between source and destination;        and/or    -   Transfer of structure information between source and        destination; and/or    -   Indication of lost, duplicated or errored information that is        not recovered by RPR data link if needed.        9.3.2 Primitives Between XP and the XP User        9.3.2.1 General

At the Service Access Point (SAP) of XP layer, the following primitivesis used between the XP and the TCE layer:

-   -   From a TCE layer to the XP, XP-UNACK-DATA Request;    -   From the XP to the TCE layer, XP-UNACK-DATA Indication.    -   From the XP to the management entity; LMXP-ERROR Indication.

A XP-UNACK-DATA request primitive at the local XP-SAP will result in aXP-UNACK-DATA indication primitive at its peer XP-SAP.

9.3.2.2 Definition of XP Primitives

9.3.2.2.1 XP-UNACK-DATA Request (Be Not Used to Signalling Frames)

X3 -UNACK-DATA request (USERDATA [Necessary],

-   -   STRUCTURE [optional])

The XP-UNACK-DATA request primitive requests the transfer of the XP-SDU,i.e. contents of the USERDATA parameter, from the local XP entity to itspeer entity. The length of the XN-SDU and the time interval between twoconsecutive primitives is constant. These two constants are a functionof the XP service provided to the TCE layer.

9.3.2.2.2 XP-UNACK-DATA Indication (Be Not Used to Signalling Frames)

XP-UNACK-DATA indication (USERDATA [Necessary],

-   -   STRUCTURE [optional],    -   ERROR [optional])

A XP user is notified by the XP that the XP-SDU, i.e. contents of theUSERDATA parameter, from its peer is available. The length of the XP-SDUand the time interval between two consecutive primitives should beconstant. These two constants are a function of the XP service providedto the TCE layer.

9.3.2.2.3 LMXP-ERROR Indication

LMP-ERROR indication (T_error [Necessary],

-   -   REG_lost [optional],    -   REG_duplicated [optional])

REG_lost and REG_duplicated parameters are used to identify how manysequence frames are lost and duplicated by FSN detection from thetransmit side to receive side in the specific period (T_error). Oncesequence lost or duplicated is occurred, LMXP-ERROR indication will beapplied.

9.3.2.4 Definition of Primitive Parameters

9.3.2.4.1 USERDATA Parameter

The USERDATA parameter carries the XP-SDU to be sent or delivered. Thesize of each block to be delivered depends on the specific XP layerservice used. For the same type of TCE payload, i.e. ITU-T G.702 PDHcircuit, the payload length of XP-PDU is constant and default is set to512 octets. For the supported TCE payloads, the payload length ofXP-PDUs is defined as following. TABLE 14 Selection of Default PayloadLength of XP-PDU Default Payload Length of Types of TCE payload XP-PDU(octets) G.702 PDH circuit - Synchronous circuit transport 512 G.702 PDHcircuit - Asynchronous circuit transport 512 Video signal - Distributivetelevision services 188 Video signal - Conversational services of bitrates 188 higher than primary rates Video signal - Conversationalservices of p × 64 kbit/s 188 signals Voiceband signal - 64 kbit/s A-lawor μ-law coded 512 Patent G.711 signals Digital channel supported by 64kbit/s-based ISDN - 512 Transport of 64 kbit/s channel Digital channelsupported by 64 kbit/s-based ISDN - 512 Transport of 384, 1536 or 1920kbit/s channel9.3.2.4.2 STRUCTURED Parameter (Option of XP-UNACK-DATA Primitive)

The STRUCTURED parameter can be used when the data stream of TCE layerto be transferred to the peer XP entity is organized into groups ofbits. The length of the structured block is fixed for each instance ofthe XP service. The length is an integer multiple of 32 bits. An exampleof the use of this parameter is to support circuit mode bearer servicesof the 64 kbit/s-based ISDN. The two values of the STRUCTURED parameterare:

-   -   BOUND and    -   DATA-STREAM.

The value BOUND is used when the USERDATA is the first part of astructured block which can be composed of consecutive USERDATA. In othercases, the structure parameter is set to DATA-STREAM. The use of theSTRUCTURED parameter depends on the type of XP service provided. The useof this parameter is agreed prior to or at the connection establishmentby network management between the TCE layer and the Data Link layer. Inmost application, the function of “STRUCTURE parameter” has been coveredby the transform and adaptation function of Flow at the Flow interfacewithin a node since XP uses pre-plan and connection oriented policy, andTCCR is made (e.g. ISDN 64 kb/s Flow source in a node to ISDN 64 kb/sFlow sink, E1 (2048 kbit/s) Flow source in a node to E1 (2048 kbit/s)Flow sink) by network management entity or control signalling beforeFlow service is operated on-line.

9.3.2.4.3 ERROR Parameter (Option of XP-UNACK-DATA Primitive)

The ERROR parameter is involved to identify that the USERDATA is erroredor non-errored. The ERROR parameter has two values:

-   -   NO and    -   YES.

The “YES” value does imply that the USERDATA covers a dummy value withinthis frame. The “NO” value implies that the no error is found fromtransmit to receive side. The use of the ERROR parameter and the choiceof dummy value depend on the type of XP service provided. The use ofthis parameter is agreed prior to or at the connection establishment ofTCCR between the TCE layer and the XP layer.

9.3.2.4.4 T₁₃ error, REG_lost and REG_duplicated Parameters

The connection management entity is used to monitor the error status ofreceiving the peer link frame at peer-to-peer level. It is local matteronly and has not any associated frame to be used between the two sides.

REG_lost and REG_duplicated parameters are attached to LMXP-ERRORIndication primitive to identify how many sequence frames are lostand/or duplicated from the transmit side to receive side in the specificperiod (T_error). Their accumulation values are stored and transformedto the two specific registers in the receive side. The parameter T_errorin the unit of second is an initial value (15 minutes and 24 hours aretwo default values) and configurable by the network management entityaccording to the rate of specific service over XP. Each Flow has thecorresponding REG_lost and REG_duplicated, and is separated operatedfrom other Flow. At the beginning of RPR Data Node start-up, theREG_lost and REG_duplicated of each Flow are clear and set to zero.

-   -   If the timer T_error expires before no lost or duplicated frames        are received, the link entity shall restart timer T_error. The        XP entity shall not indicate this to the local connection        management entity.    -   Once the timer T_error expires if any lost or duplicated frame        is received, the XP entity shall indicate this to the local        connection management entity by means of the LMXP-ERROR        indication primitive, and restart timer T_error.        9.4 Supported Functions of XP for TCE Case

The following functions can be performed in the XP in order to meetrequirements of TDM (Time Division Multiplex) timing, structure, jitterand wander:

-   a) source clock frequency recovery at the receiver;-   b) recovery of the source data structure at the receiver;-   c) blocking and deblocking of XP user information;-   d) control of frame latency variation;-   e) processing of lost or duplicated frames;

NOTE—For some XP users, the end-to-end QOS monitoring may be needed toprovide. This function can be achieved by calculating a CRC, reportinglost or duplicated frames in the default period (e.g. 15 minutes and 24hours) for the XP-PDU, A corresponding periodic count of CRCcomputation, values of REG_lost and REQ_duplicated are sent to networkmanagement entity.

9.4.1 TCE Processing Mode

9.4.1.1 Processing Mode of G.702 PDH

For this sub-section, it is necessary to identify TCE data structure andthe clock operation mode at the XP service boundary, i.e. framing ornon-framing, types of clock (synchronous or asynchronous) where neededto make comparison to a network clock. Asynchronous and synchronous TCEtransport provides transport of signals from TCE sources whose clocksare non-frequency-locked and frequency-locked to a network clockrespectively. The judgement of synchronous or asynchronous will dependon the service provided by the specific network, i.e. PDH, SDH, or ISDN.Care should be taken to select the shortest transport path, controlpriority of delivery and transient, and reduce transport latency andlatency variation along RPR during the project installation phase.

1) Asynchronous G.702 Circuit Circuit rate at XP service boundary:1.544, 2.048, 6.312, 8.448, 44.736 and 34.368 Mbit/s as specified inPatent G.702. Payload size to be encapsulated: see Table 14 Source clockfrequency recovery: Asynchronous frequency Error status indication atthe receiver: count report of lost or duplicated frames by LMXP-ERRORIndication primitive.

2) Synchronous G.702 Circuit Circuit rate at XP service boundary: 1.544,2.048, 6.312, 8.448, 44.736 and 34.368 Mbit/s as specified in PatentG.702. Payload size to be encapsulated: see Table 14 Source clockfrequency recovery: Synchronous timing Error status indication at thereceiver: count report of lost or duplicated frames by LMXP-ERRORIndication primitive.9.4.1.2 Processing Mode of Video Signal Transport

This sub-section presents the processing mode of Video signal transport.Care should be taken to select the shortest transport path, controlpriority of delivery and transient, and reduce transport latency andlatency variation along RPR during the project installation phase.

1) Mode of Conversational Services of p×64 kbit/s Signals

This sub-section gives the processing mode of interactive video signalsof the p×64 videotelephony and videoconference applications as specifiedin Patent H.320. a) Circuit rate at XP service boundary: 384, 1536 or1920 kbit/s in the 64 kbit/s-based ISDN by using H0, H11, H12,respectively. b) Payload size to be encapsulated: see Table 14 c) Sourceclock frequency recovery: Synchronous timing d) Error status indicationat the receiver: count report of lost or duplicated frames by LMXP-ERRORIndication primitive.2) Mode of Distributive Television Services

This sub-section illustrates transport of distributive televisionsignals encoded by using MPEG2 with a constant bit rate specified inPatent J.82. a) Circuit rate at XP service boundary: Depending on MPEG2parameters b) Payload size to be encapsulated: see Table 14 c) Sourceclock frequency recovery: Asynchronous frequency d) Error statusindication at the receiver: count report of lost or duplicated frames byLMXP-ERROR Indication primitive.3) Mode of Conversational Services of Bit Rates Higher Than PrimaryRates

This sub-section illustrates transport of interactive video signals for,i.e. video-telephony and conference application specified inRecommendation H.310. a) Circuit rate at XP service boundary: Dependingon H.310 parameters b) Payload size to be encapsulated: see Table 14 c)Source clock frequency recovery: Synchronous/Asynchronous per PatentH.310 d) Error status indication at the receiver: count report of lostor duplicated frames by LMXP-ERROR Indication primitive. Patent H.310should be taken into account.9.4.1.3 Processing Mode of Digital Channel Supported by 64 kbit/s-BasedISDN

This sub-section presents the processing mode of digital channelsupported by 64 kbit/s-based ISDN. Care should be taken to select theshortest transport path, control priority of delivery and transient, andreduce transport latency and latency variation along RPR during theproject installation phase. 1) Mode of 64 kbit/s channel a) Circuit rateat XP service boundary: 64 kbit/s b) Payload size to be encapsulated:see Table 14 c) Source clock frequency recovery: Synchronous timing d)Error status indication at the receiver: count report of lost orduplicated frames by LMXP-ERROR Indication primitive. 2) Mode of 384,1536 or 1920 kbit/s channel a) Circuit rate at XP service boundary: 384,1536 or 1920 kbit/s b) Payload size to be encapsulated: see Table 14 c)Source clock frequency recovery: Synchronous timing d) Error statusindication at the receiver: count report of lost or duplicated frames byLMXP-ERROR Indication primitive.9.4.1.4 Processing Mode of Voice-Band Signal

This sub-section presents the processing mode of 64 kbit/s A-law orμ-law coded Patent G.711 signals. Care should be taken to select theshortest transport path, control priority of delivery and transient, andreduce transport latency and latency variation along RPR during theproject installation phase. a) Circuit rate at XP service boundary: 64kbit/s b) Payload size to be encapsulated: see Table 14 c) Source clockfrequency recovery: Synchronous timing d) Error status indication at thereceiver: count report of lost or duplicated frames by LMXP-ERRORIndication primitive.9.4.2 TCE Function of MSF Data Link9.4.2.1 TCE Functions for Circuit

The following sections provide both asynchronous and synchronous TCEtransport function along RPR or other topologies. Asynchronous andsynchronous TCE supports transport of signals from constant bit ratesources whose clocks are non-frequency-locked and frequency-lockedrespectively to a network clock. Asynchronous examples are Patent G.702signals at 1.544, 2.048, 6.312, 8.448, 32.064, 44.736 and 34.368 Mbit/s,Synchronous examples are at 64, 384, 1536 and 1920 kbit/s as specifiedin Patent 1.231.

-   1) Consideration of XP user information    -   The length of the XP-SDU is 64 octets. A XP-SDU constitutes one        XP PDU payload. For those XP users, it requires a peer-to-peer        presetting of structured data, i.e. 8 kHz structured data for        circuit mode bearer services of the 64 kbit/s-based ISDN.-   2) Processing strategy of frame delay variation    -   A buffer mechanism is used to support this function. In the        event of buffer underflow, it can be necessary for the XP to        maintain bit count integrity by inserting the appropriate number        of dummy bits. In the event of buffer overflow, it may be        necessary for the XP to maintain bit count integrity by dropping        the appropriate number of bits.    -   When Patent G.702 1.544-Mbit/s and 2.048-Mbit/s signals are        being transported, the inserted dummy bits shall be all “1”s.-   3) Processing strategy of lost and duplicated frames    -   A destination XP can determine whether the frames have been lost        by tracking the Frame Sequence Number (FSN) or sequence count        values of the received XP PDUs. Detected duplicated frames are        discarded.    -   In order to maintain the bit count integrity of the XP user        information, it may be necessary to compensate for lost frames        detected by buffer underflow and sequence count processing by        inserting the appropriate number of dummy payloads. The content        of this dummy payload depends on the XP service being provided.        For example, this dummy payload is all “1”s for Patent G.702        1.544 Mbit/s and 2.048-Mbit/s signals.-   4) Guaranty of jitter and wander    -   This function is required for delivery of XP-SDUs to a XP user        at a constant bit rate. Recovered source clock should meet the        requirement of jitter and wander performance of the related        Patent defined. For example, the jitter and wander performance        for Patent G.702 signals is specified in Patents G.823 and        G.824, for which the XP procedure to be used.        9.4.2.2 TCE Functions of Video Signal

The following sections present processing of video signals forinteractive and distributive services:

-   1) Consideration of XP user information    -   The length of the XP-SDU is 188 octets. A XP-SDU constitutes one        XP PDU payload. For those XP users, it requires a peer-to-peer        presetting of structured data. Depending on the type of XP        service provided (i.e. the interface to the XDP user), the ERROR        parameter will be passed to the XP user to facilitate further        picture processing.-   2) Processing strategy of frame delay variation    -   A buffer mechanism is used to support this function. The size of        this buffer is dependent upon specifications video signal. In        the event of buffer underflow, it may be necessary for the XP to        maintain bit count integrity by inserting the appropriate number        of dummy bits. In the event of buffer overflow, it may be        necessary for the XP to maintain bit count integrity by dropping        the appropriate number of bits.-   3) Processing of lost and duplicated frames    -   A destination XP can determine whether the frame has been lost        by tracking the Frame Sequence Number (FSN) or sequence count        values of the received XP PDUs. Detected duplicated frames are        discarded.    -   In order to maintain the bit count integrity of the XP user        information, it may be necessary to compensate for lost frames        detected by buffer underflow and sequence count processing by        inserting the appropriate number of dummy payloads. The content        of this dummy payload depends on the XP service being provided.    -   Information in lost frames may be recovered by the mechanism        described in 9.5.1.-   4) Guaranty of jitter and wander    -   This function is required for delivery of XP-SDUs to a XP user        at a constant bit rate. Some XP users may require source clock        frequency recovery, i.e. recovery in the receive side of camera        clock frequency that is not locked to the network clock.        9.4.2.3 TCE Functions of Voice-Band Signal

The following sections support processing of a single voice-band signal,i.e. one 64 kbit/s A-law or μ-law coded Patent G.711 signal.

-   1) Consideration of XP user information    -   The length of the XP-SDU is 64 octets. A XP-SDU constitutes one        XP PDU payload.-   2) Processing of frame delay variation    -   A buffer mechanism is used to support this function. The size of        this buffer depends on specifications provided in voice-band        signal.-   3) Processing strategy of lost and duplicated frames    -   For voice-band signals, there is a need still to detect        duplicated and lost frames.    -   The receiving XP entity must detect/compensate for lost frame        events to maintain bit count integrity and must also minimize        the delay, i.e. to alleviate echo performance problems, in        conveying the individual voice-band signal octets from the        XP-PDU payload to the XP user. The receiving XP entity may take        actions based on the received Sequence Number values, but such        actions must not increase the conveyance delay across the XP        receiving entity to alleviate echo performance problems.    -   The XP receiving entity must accommodate a sudden increase or        decrease in the nominal frame transfer delay. (A protection        switching event in the RPR may result in a change of transfer        delay.)-   4) Guaranty of jitter and wander    -   The XP provides synchronous circuit transport for the voice-band        signal.    -   NOTE 1—Example receiver techniques use a timing-based mechanism        or a buffer-fill-based mechanism, possibly supplemented by a        Sequence Number processing algorithm that does not introduce        additional delay.    -   NOTE 2—For transporting signals of speech and 3.1 kHz audio        bearer services as specified in 64 kbit/s ISDN, the need for        A/μ-law conversion is identified. The conversion between A-law        and μ-law coded PCM octets are as specified in Patent G.711.        This conversion function is outside the scope of this Patent.        9.4.2.4 TCE Functions of High Quality Audio Signal

The case is the same as the above. The TCE functions of high qualityaudio signals in XP include the following capabilities in principle.

-   -   a) Consideration of XP user information;    -   b) Processing strategy of frame delay variation;    -   c) Processing of lost and duplicated frames;    -   d) Guaranty of jitter and wander;        9.5 XP Protocol Involved to Support TCE

The following sub-sections describe XP procedures to be provided forimplementing XP functions involved to support TCE.

9.5.1 Processing Strategy of Frame Sequence Number (FSN)

9.5.1.1 Processing in the Transmit Side

The XP provides a sequence count value and a XP indication associatedwith each XP-PDU payload in the transmit side. The count value appliedto FSN field starts with 0, is incremented sequentially to 63 and isnumbered modulo 64 when FT field is set to support TCE function. Whenthe data link frames carrying TCE payloads traverse a RPR or othertopologies, then may arrive destination station disorderly. Due to thisreason, it is required that frames must be delivered in order. Ensuringin-order delivery is also effective approach to out-of-order detection.

9.5.1.2 Processing in the Receive Side

The XP receives and derives the following information associated witheach XP-PDU payload in receive side:

-   -   sequence number;    -   count;    -   check error of the frame sequence number and count.

The implementation of sequence count values and number will be specifiedon a service specific basis (e.g. REG_lost and REG_duplicated). The XPentity in the receive side identifies lost or duplicated XP-PDUpayloads.

XF entity tracks the following status of dynamic data stream:

-   -   XP-PDU payload sequence number and count;    -   XP-PDU payload loss (if occur);    -   XP-PDU payload duplication (if occur).

There are two ways to solve the real-time processing problem, (1) try toreorder and sort into the correct order or (2) drop those disorderingframes, when disordering case occurred. In implementation, These twomethods should be all supported. If method (1) does not meet reliabilitytransport and performance requirement still, the method (2) will beapplied. Due to the limitation of native speed and acceptable delay ofdata link payloads listed in Table 14, this Patent does not supportcorrection method for bit errors and frame losses.

9.5.2 Recovery Method of Timing and Structured Information

To support TCE services available in Table 14, the requirements oftiming and structured information should be based on the nativecharacteristics of the these services, and it is necessary for theseTCEs to recover these signal characteristics as closely specified in therelated standard as possible in the receive side, including the signaljitter, bit-rate, timing characteristics and structured informationtransfer (if it has) as it was sent. In most application, STRUCTUREinformation could be provided by the transform and adaptation functionof Flow at the Flow interface within a node since XP uses pre-plan andconnection oriented policy, and TCCR is made (e.g. ISDN 64 kbit/s Flowsource in a node to ISDN 64 kbit/s Flow sink, E1 Flow source in a nodeto E1 Flow sink) by network management entity or control signallingbefore Flow service is operated on-line.

For the timing issue of MSF, the four methods that could be used toengineering projects are: (a) timing (synchronous) signallingbroadcasted periodically from that designated station with an externalsynchronous source along the MSF or other topologies; (b) timing(synchronous) information received from an external facility forreferencing to all stations; (c) timing (synchronous) informationreceived from an external facility for referencing to a said centralstation, other stations along a ring will get timing information fromthe line side and reference to the central station. (d) No timing(synchronous) information and referencing to MAC sublayer. If the method(a) is applied, the primitives are defined as follows.

-   -   SYNCHRONIZATION Request (NA, T_sync)

The signalling frame of SYNCHRONIZATION Request primitive will have thehighest priority among all other signalling frame defined in this Patentand be operated in a way of broadcast. The broadcasted period is TimerT₁₃ sync. Its default value is 8000 frames per second. This value isprogrammable and can be changed by network management entity.

-   -   SYNCHRONIZATION Confirm (Non parameter)

After getting the signalling frame of SYNCHRONIZATION Request, eachstation along a ring will align the phase relations of its oscillatorfacility (including frequency-locked) and send SYNCHRONIZATION Confirmsignalling frame with lower priority to the source station initiated thesignalling frame of SYNCHRONIZATION Request. The codes of these twosignalling frames are listed in the Table 4.

Since the service types and connection relations of TCEs from source todestination, including Node address, FT and FN, are pre-plan beforeservice Flow is operated, the initial timing (except for phase relationsand actual bit-stream) and structured information should be pre-set byconfiguration function of network management entity before those TCEservices are available. The phase relations and actual bit-stream of TCEsignals are designed to perform the extraction of output transmissionbit timing information from the received frame stream, and requires aphase-locking mechanism. It is recommended that method (d) is firstchoice in this Patent.

9.5.3 Services from MAC

The services provided from the MAC sublayer allow: a) The peer-to-peerFlow data exchange; b) The parameters exchange between MAC and XPentity; c) The data exchange across MSF by the bridge. The RPR MACprovides strict and relaxed frame transmission service. The MAC sublayerpresents a service interface for the exchange of XP PDUs between XPentities. The MAC service interface supports service classes denotedclass A, class B, and class C. For all service classes, the MAC serviceinterface provides per ringlet indications to XP of whether traffic canor cannot currently be accepted. For service class C, the MAC serviceinterface also provides the number of hops to the nearest congestedstation. Each service class is rate controlled to prevent XP fromtransmitting more traffic than was allocated or allowed by fairness, asapplicable.

9.5.3.1 Services Class A

Class A (real-time service) service provides an allocated, guaranteeddata rate and a low end-to-end delay and jitter bound. Within thisclass, there is a mechanism to reserve some or all of the allocatedbandwidth. Fairness Eligible (FE) bit in the RPR header must always beset to 0 on class A traffic. Class A traffic moves through the primarytransit path in each station as it propagates around the ring.

9.5.3.2 Services Class B

Class B (near real-time service, allocated or opportunistic) serviceprovides an allocated, guaranteed data rate, optional additional datarate that is not allocated or guaranteed, and bounded end-to-end delayand jitter for the traffic within the allocated rate. Class B hassimilarities to the class A service and also has similarities to class Cservice, in which traffic beyond the allocated rate profile is subjectto the fairness algorithm, and is marked by the MAC as such with thefairness eligible (FE) bit in the RPR header prior to transmission onthe ring. In a single-queue or a dual-queue implementation, class Btraffic moves through the primary transit path or secondary transitpath, regardless of whether the frame is marked fairness eligible ornot.

9.5.3.3 Services Class C

Class C (best-effort service, opportunistic) service provides abest-effort traffic service with no allocated or guaranteed data rateand no bounds on end-to-end delay or jitter. Class C traffic is alwayssubject to the fairness algorithm, and is marked by the MAC as such withthe fairness, eligible (FE) bit in the RPR header prior to transmissionon the ring. In a single-queue implementation, class C traffic movesthrough the primary transit path. In a dual-queue implementation, classC traffic moves through the secondary transit path.

9.6 Management Function Involved to Support TCE

The following functions is required to be provided to the networkmanagement entity:

9.6.1 TCE Property (Including Structured Information of Data Stream)Mismatch Between the Source and Destination

The related operation is described detailed and refer to section 5.6.

10 Flow Based Protection (FBP)

The Flow of this section is a logical service channel defined in section3, such as Ethernet, TCEs with a fixed value of Flow Type (FT) and FlowNumber (FN) in the frame format. The application scope of Flow basedprotection involved in this section is located at full-duplexpoint-to-point application only. The flow protection operation ofhalf-duplex point-to-point, multicast and broadcast will not be thescope of this section. A Node of RPR can provide support of multipleEFBP and Multiple TFBP at the same time.

A 1+1 unidirectional protection architecture has one normal trafficsignal (packet), one working flow, one protection flow and a logicalbridge. At the source end, the normal traffic signal (packet) islogically bridged to both the working and protection flow. At the sinkend, the normal traffic signal (packet) is selected from the better ofthe two flows. Due to the logical bridging, the 1+1 architecture doesnot allow an extra unprotected traffic signal (packet) to be provided.

A 1:N unidirectional protection architecture has N normal trafficsignals (packet), N working flows and 1 protection flow which may havean extra traffic signal (packet) in case of no defect condition (or afault indication) or external commands for the N working flows. Thesignals (packet) on the working flows are the normal traffic signals(packet). The signal (packet) on the protection flow may be either oneof the normal traffic signals (packet), an extra traffic signal(packet), or the null signal (packet). At the source side, one of thesesignals (packet) is connected to the protection flow. At the sink side,the signals (packet) from the working flows are selected as the normalsignals (packet). When a defect condition or a fault indication isdetected on a working flow or under the influence of certain externalcommands, the transported signal (packet) is bridged to the protectionflow. At the sink side, the signal from this protection flow is thenselected.

10.1 Ethernet Flow Based Protection (EFBP)

When needed to support the EFBP Function, EFBP Function Unit embedded inthe corresponding Flow part of XP entity as an attachment in XP entitywill be activated by the configuration function of network managemententity (this configuration function is performed either in theprojection installation phase or MSF on-line operation phase) and thecorresponding Flow is set to a Working Flow.

For Operation of 1+1 EFBP, it is needed to designate a mate Standby Flowwith the same service property, source and destination. The payloads ofthe mate Working Flow and Standby Flow will carry the same traffic.

For 1:1 EFBP, it is also needed to designate a mate Standby Flow withthe same service property, source and destination. The payloads of theStandby Flow use an extra traffic signal (packet) in case of no defectcondition (or a fault indication) or external commands for the workingflow (Once ETBP occurred for this Working Flow, the extra traffictransport will be stopped by a bridge function).

For 1:N EFBP, there are multiple Working Flows (e.g. number is N), it isalso needed to designate a mate Standby Flow with the same serviceproperty, source and destination. The payloads of the Standby Flow cancarry an extra traffic signal (packet) in case of no defect condition(or a fault indication) or external commands for the N working flow(Once EFBP in one of N Working Flow occurred, this additional traffictransport will be stopped by a bridge function).

The CS operational codes of EFBP are listed in the Table 15. TABLE 15Codes of ETBP frame CS Frame Types Codes 1+1 EFBP_Request Frame 001000011+1_EFBP_Response Frame 00100010 1:1 EFBP_Request Frame 001000111:1_EFBP_Response Frame 00100100 1:N EFBP_Request Frame 001001011:N_EFBP_Response Frame 00100110Note 1:1+1 and 1:1 EFBP_Request Frame is a multicast frame and should be issuedto four ends of two targeted Flows (including the working and standbyflows) at the same time.1:N EFBP_Request Frame is a multicast frame and should be issued tomultiple ends of targeted Flows (including the N working flows and astandby flow) at the same time.Note 2:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.

The parameters of 1+1 EFBP_Request Frame and 1:1 EFBP_Request Frame havethe same format as that of the unicast mode of TCCR ID. This parameterconsists of FNi ID (This is an identifier of Flow p within node x),2-bit U/M/B field (6-bit is reserved and set to binary 000000), 8-bitlength field (This filed is used to reflect the total number of Flow FNjID following length field, its value should be binary 000001 00000001for 1+1, binary 000010 00000001 for 1:1) and a FNj ID (This is anidentifier of Flow q within node y).

FIG. 12 Shows Expressions of 1+1 and 1:1 Flow Protection Parameters.

Note: FNi ID=NAx(x=1,2,3 . . . 256)+FT+FNp (p=0,1,2,3, . . . 2²⁰-1), toidentify the path Flow with the fixed FT and FN value within xth node.FNi ID and FNj ID stand for standby and working flow respectively.

The parameters of 1+1 EFBP_Response Frame and 1:1 EFBP_Response Frameare the same as that of 1+1 EFBP_Request Frame and 1:1 EFBP_RequestFrame respectively.

The parameters of 1:N EFBP_Request Frame have the same format as that ofthe multicast/broadcast mode of TCCR ID. This parameter also consists ofFNi ID (This is an identifier of Flow p within node x), 2-bit U/M/Bfield (6-bit is reserved and set to binary 000000), 8-bit length field(This filed is used to reflect the total number of Flow FNj ID followinglength field, its value should be binary 000011 00000100 if N=4) and aFNj ID (This is an identifier of Flow q within node y).

FIG. 13 Shows Expressions of 1:N Flow Protection Parameter.

Note: FNi ID=NAx(x=1,2,3 . . . 256)+FT+FNp (p=0,1,2,3, . . . 2²⁰-1), toidentijy the path Flow with the fixed FT and FN value within xth node.FNi ID is used to present standby flow, and FNi ID, FNk ID, FNl ID andFNm ID etc represent working flow, the total number is N.

The parameters of 1+1 EFBP_Response Frame, 1:1 EFBP_Response Frame and1:N EFBP_Response Frame are specified in the Table 16. TABLE 16Parameters of EFBP_Response Frame CS Frame Types Codes EFBP successfulBinary “00000001 00010001 00000001 00000000” EFBP unsuccessful Binary“00000001 00010010 00000001 00000000”Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.

The EFBP Function Unit is used to monitor the link status of receivingthe peer link frames at the reference point T1/T2. It is local matteronly and has not any associated frame to be used between the two sides.

-   -   After initialization (the defaults of T_efbp and N_efbp are set        to 10 milliseconds and 4 respectively), the link entity enters        the normal way of transmitter and receiver.    -   If the timer T_efbp expires before any MAC frame is received or        status report from MAC layer by MA_CONTROL Indication or MA_DATA        Indication occurs with one or more opcodes (receptionStatus,        serviceClass, topochange, protchange), the link entity shall        restart timer T_efbp and decrement the retransmission counter        N_efbp.    -   If the timer T_efbp expires and retransmission counter N_efbp        has been decremented to zero. before any MAC frame from the        trunk is received or status report from MAC layer by MA_CONTROL        Indication or MA_DATA Indication is kept still with one or more        opcodes (receptionStatus, serviceClass, topochange, protchange),        the link entity of the trunk shall inform the all local Flow        entities (within a node), which are set to have the other        protection Flow, and send a periodic Error-Hello message from        entity of the trunk to those entities of Flow within that node.

After getting Error-Hello, the local Flow entity will perform an actionof ETBP (1+1, 1:1 or 1:N) to the corresponding Standby Flow within thesame node, change previous transmission channel of trunk to thecounter-rotating ringlet of pre-setting. After the entity of Flow entersinto the normal transmission operation, the local trunk entity willrestart timer T_efbp and recover the value of N_efbp. Every Standby Flowhas its T_efbp and N_efbp of itself.

-   -   For the case of 1:1 and 1:N, after the EFBP Function Unit        receives a periodic Error-Hello message, the link entity in the        transmit side will perform an action of EFBP (1:1 or 1:N) to the        corresponding Standby Flow.    -   The value of T_efbp and N_efbp shall be configurable. The        minimum unit configured of T_efbp and N_efbp is 1 milliseconds        and 1 respectively.

Once EFBP Function Unit detects that the failure span is recovered andenters normal status from the EFBP (that is, stop Error-Hello Message),EFBP Function Unit will wait T_efbp_wtr (The default to 10 minutes, itsvalue is also programmable and should be much greater than T_efbp), andthen switch to the Working Flow. After switching to the Working Flow,EFBP Function Unit issues, an EFBP_RECOVERY_EVENT_Report with parametersof FT and FN to network management entity.

10.2 TCE Flow Based Protection (TFBP)

When needed to support the TFBP function, TFBP Function Unit embedded inthe corresponding Flow in XP entity will be activated by theconfiguration of network management (this configuration is performedeither in the projection installation phase or on-line operation phase)and the corresponding Flow is set to a Working Flow.

For Operation of 1+1 TFBP, it is needed to designate a mate Standby Flowwith the same service property, source and sink. The payloads of themate Working Flow and Standby Flow carrying the same traffic arerequired.

For 1:1 TFBP, it is also needed to designate a mate Standby Flow withthe same service property, source and sink. The payloads of the StandbyFlow can run an extra traffic signal (packet) in case of no defectcondition (or a fault indication) or external commands for the workingflow (Once TFBP occurred for this Working Flow, the extra traffictransport will be stopped by a bridge function).

For 1:N TFBP, there are N Working Flows; it is also needed to designatea mate Standby Flow with the same service property, source and sink. Thepayloads of the Standby Flow can run an extra traffic signal (packet) incase of no defect condition (or a fault indication) or external commandsfor the working flow (Once TFBP in one of N Working Flow occurred, thisadditional traffic transport will be stopped by a bridge function).

The CS operational codes of TFBP are listed in the Table 17. TABLE 17Codes of TFBP frame CS Frame Types Codes 1+1 TFBP_Request Frame 001001111+1_TFBP_Response Frame 00101000 1:1 TFBP_Request Frame 001010011:1_TFBP_Response Frame 00101010 1:N TFBP_Request Frame 001010111:N_TFBP_Response Frame 00101100 TFBP_RECOVERY_EVENT_Report 00101101Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.Note 2:1+1 and 1:1 TFBP_Request Frame is a multicast frame and should be issuedto four ends of two targeted Flows (including the working and standbyflows) at the same time.1:N TFBP_Request Frame is a multicast frame and should be issued tomultiple ends of targeted Flows (including the N working flows and astandby flow) at the same time.

The parameters of the 1+1, 1:1 and 1:N TFBP Response fame in thissub-section are specified in Table 18. TABLE 18 Parameters of BandwidthLimitation_Response Frame CS Frame Types Codes TFBP successful Binary“00000001 00010011 00000001 00000000” TFBP unsuccessful Binary “0000000100010100 00000001 00000000”Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives

The parameters of 1+1 TFBP_Request Frame and 1:1 TFBP_Request Frame havethe same format as that of the unicast mode of TCCR ID. This parameterconsists of FNi ID (This is an identifier of Flow p within node x),2-bit U/M/B field (6-bit is reserved and set to binary 000000), 8-bitlength field (This filed is used to reflect the total number of Flow FNjID following length field, its value should be binary 000000 00000001)and a FNj ID (This is an identifier of Flow q within node y).

FIG. 14 Shows Expressions of 1+1 and 1:1 Flow Protection Parameters.

Note: FNi ID=NAx(x=1,2,3 . . . 256)+FT+FNp (p=0,1,2,3, . . . 2²⁰-1), toidentify the path Flow with the fixed FT and FN value within xth node.FNi ID and FNj ID stand for standby and working flow respectively.

The parameters of 1+1 TFBP_Response Frame and 1:1 TFBP_Response Frameare the same as that of Request primitives above.

The parameters of 1:N TFBP_Request Frame have the same format as that ofthe multicast/broadcast mode of TCCR ID. This parameter also consists ofFNi ID (his is an identifier of Flow p within node x), 2-bit U/M/B field(6-bit is reserved and set to binary 000000), 8-bit length field (Thisfiled is used to reflect the total number of Flow FNj ID followinglength field, its value should be binary 000000 00000001) and a FNj ID(This is an identifier of Flow q within node y). Please refer to as FIG.15.

FIG. 15 Shows Expressions of 1:N Flow Protection Parameter.

Note: FNi ID=NAx(x=1,2,3 . . . 256)+FT+FNp (p=0,1,2,3, . . . 2²⁰-1), toidentify the path Flow with the fixed FT and FN value within xth node.FNi ID is used to present standby flow, and FNi ID, FNk ID and FNm IDetc represent working flow, the total number is N.

The TFBP Function Unit is used to monitor the link status of Flow bymonitoring the peer link frames of an trunk. Normally, the entity in thereceive side of trunk does always receive or transit the MAC frame fromthe upstream node. No link-error occurs and no Error-Hello is also sentto the local Flow entity within a node. It is local matter only and hasnot any associated frame to be used between the two sides.

-   -   After initialization (the defaults of T_tfbp and N_tfbp are set        to 10 milli-seconds and 3 respectively), the link entity enters        the normal way of transmitter and receiver.    -   If the timer T_tfbp expires before any MAC frame from the trunk        is received or status report from MAC layer by MA_CONTROL        Indication or MA_DATA Indication occurs with one or more opcodes        (receptionStatus, serviceClass, topochange, protchange), the        link entity of trunk shall restart timer T_tfbp and decrement        the retransmission counter N_tfbp.    -   If the timer T_tfbp expires and retransmission counter N_tfbp        has been decremented to zero before any MAC frame from the trunk        is received or status report from MAC layer by MA_CONTROL        Indication or MA_DATA Indication occurs with one or more opcodes        (receptionStatus, serviceClass, topochange, protchange), the        link entity of the trunk shall inform the all local Flow        entities (within a node), which are set to have the related        protection switch flag to other protection Flow, and send a        Error-Hello message from the trunk entity to those entities of        Flow within that node. After getting Error-Hello, the local Flow        entity will perform an action of TFBP (1+1, 1:1 or 1:N) to the        corresponding Standby Flow within the same node, change previous        transmission channel of trunk to the counter-rotating ringlet of        pre-setting. After the entity of Flow enters into the normal        transmission operation, the local trunk entity will restart        timer T_tfbp and recover the value of N_tfbp. Every Standby Flow        has its T_tfbp and N_tfbp of itself.    -   The value of T_tfbp and N_tfbp shall be configurable. The        minimum unit configured of T_tfbp and N_tfbp is 1 milliseconds        and 1 respectively.

Once TFBP Function Unit detects that the failure span is recovered andenters normal status from the TFBP, TFBP Function Unit will waitT_tfbp_wtr (The default to 10 minutes, its value is also programmableand should be much greater than T_tfbp), and then switch to the WorkingFlow. After switching to the Working Flow, TFBP Function Unit issues aTFBP_RECOVERY_EVENT_Report with parameters of FT and FN to networkmanagement entity.

11 Flow Based Multicast (FBM)

The Flow of this section is a logical service channel defined in section3, such as TCE or Ethernet with a fixed value of Flow Type (FT) and FlowNumber (FN) in the MSF frame. The application scope of Flow BasedMulticast (FBM) is located at the operation of half-duplexpoint-to-multi-point only. The full-duplex point-to-point will not berecommended to the scope of this section.

The FBM Function Unit built in a Node is defined to support one or moreindependent hierarch of multicast (or broadcast) possibly involved thesame or different FT at the same time. FBM Function Unit implements aduplication function within a node (station) from a Flow getting apayload of a frame from the related topologies to other multiple Flowwith the same FT value and with being set to have a relation ofmembership group. A group of FN with the same FT value within a Node canbe set to become a membership group of multicast/broadcast. It isrequired that a designated Flow in the membership group should receivedata frames at the reference point G1 from the related topologies. Alldesignated Flow in the membership group is only allowed to get packetsfrom ST, and is not permitted to receive all other data packets. ThisPatent defines the specific designated flow that gets the node basedpacket from MSF, as a Source Flow (ST). Once getting data frames eitherfrom MAC frame or from flow side, the ST duplicates those frames toevery Flow in the corresponding membership group within a node. The STshould be set and designated to a given value of FT and FN by networkmanagement entity during the project installation phase or on-lineoperation phase. The one or more STs can be designated or changeddynamically within a node according to the customer requirements.

The CS operational codes of TBM are listed in the Table 19. TABLE 19Codes of TBM frame CS Frame Types Codes FBM_Request Frame 00101101FBM_Response Frame 00101110Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.

If a FBP is applied to operation of FBM, it is recommended that a ST bedesignated to a Working Flow, and the ST can also be operated to becomethe working Flow of 1+1 and 1:1 application described in section 10.1and 10.2.

The parameters of FBM-Request and FBM-Response frame in this sub-sectionare specified in Table 20 if the multicast/broadcast field is changedfrom “01” to “10” or “11”. TABLE 20 Parameters of FBM_Response Frame CSFrame Types Codes FBM successful Binary “00000001 00010101 0000000100000000” FBM unsuccessful Binary “00000001 00010110 00000001 00000000”Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.12 Bandwidth Policing, Merging, Line-Speed Filtering, Stacking andMirroring of Flow12.1 Flow Based Policing—Bandwidth Limitation with Symmetry andAsymmetry

TCE rate at XP service boundary should be operated and be fullycompliant with the IEEE 802.3, G.702, ISDN and other related standardsin the normal case. But in some application of service level agreement,the policy of operation and maintenance needs a limitation for rate toperform the bandwidth-based accounting. The MSF entity provides aBandwidth Limitation Function Unit. When this Function Unit is activatedto a Flow, this Flow provides configuration incremental level withminimum unit granularity (64 k/bits for TCE) from 0 to the specifiedvalue the related standard defined. The corresponding standard values ofbandwidth are specified in the related standard and must not be passedover. Once bandwidth is set up for a Flow during project installation oron-line operation phase, this programmable threshold limit applies tothis Flow and its corresponding port. The setting of bandwidth thresholdand monitoring of actual traffic flow are performed by configurationfunction and management entity.

The CS operational codes of Bandwidth Limitation are listed in the Table21. TABLE 21 Codes of Bandwidth Limitation frame CS Frame Types CodesBandwidth Limitation_Request Frame 00101111 BandwidthLimitation_Response Frame 00110000Note 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.Note 2:Bandwidth Limitation_Request Frame is a multicast frame and should beissued to two ends of targeted Flow at the same time.

The parameter of Bandwidth Limitation_Request Frame includes thefollowing elements:

-   -   Targeted (Flow) Port A: FNi=NAx+FT+FNp    -   Targeted (Flow) Port B: FNj=NAy+FT+FNq    -   Bandwidth required to be provided from Port A to Port B: a        designated integer value (an octet) between 0 and Standard        Bandwidth, e.g. binary code:01000100 represents 68*64 k/bits        Bandwidth.    -   Bandwidth required to be provided from B to A: a designated        integer value (an octet) between 0 and Standard Bandwidth, e.g.        binary code:00100000 represents 32*64 k/bits Bandwidth (This is        an example of asymmetrical bandwidth availability), binary        code:00000000 represents no Bandwidth available, it is needed        that customers use the operation of half duplex point-to-point        from port A to port B.    -   Standard Bandwidth: the related standard (binary code of G.702        E1: 00100000) for TCE    -   Minimum Granularity: 64 k/bits (binary code:00000001) for TCE

Bandwidth from port A to port B and from port B to port A is independenteach other. The separated bandwidth can be symmetrical or asymmetrical.All of these elements will be mapped to CS frame in the above order.Bandwidth Limitation_Response Frame uses two parameters: BandwidthLimitation successful or Bandwidth Limitation unsuccessful shown in theTable 22. TABLE 22 Parameters of Bandwidth Limitation_Response Frame CSFrame Types Codes Bandwidth Binary “00000001 00010111 00000001 00000000”Limitation successful Bandwidth Binary “00000001 00011000 0000000100000000” Limitation unsuccessfulNote 1:Operation of Control frame for flow between MAC and client will beimplemented via MA_Data Request and Indication primitives.

Bandwidth Limitation of Flow Based can be used to operations of halfduplex point-to-point, full duplex point-to-point, multicast andbroadcast.

12.2 Flow Merging with Symmetry and Asymmetry

The MSF entity provides a Merging Function Unit by which up to sixteenFlows of the same FT can be merged together to form a Flow Merging Group(TMG). Up to eight TMGs can be established in a MSF or other topologynode. The TMG is similar to one logical link and is very useful when thehigher bandwidth of application is required. The member Flow of a TMGmust be of the same FT and configured in full-duplex mode. The benefitsof forming a TMG are link redundancy, trunk throughput, incrementalbandwidth and load balancing on the TMGs. Once a TMG is formed, a TMG ofTCE must be identified using only a FN value (It is usual the firstmember Flow) in the corresponding frames of data, signalling and networkmanagement. For the upper layer application over a TMG, a logicalchannel can only be seen externally.

The CS operational codes of Flow Merging are listed in the Table 23.TABLE 23 Codes of Flow Merging frame CS Frame Types Codes FlowMerging_Request Frame 00110001 Flow Merging_Response Frame 00110010Note 1: Operation of Control frame for flow between MAC and client willbe implemented via MA_Data Request and Indication primitives.

The parameter of Flow Merging_Request Frame includes the followingelements:

-   -   First Targeted Flow: FNi=NAx+FT+FNp    -   Second Targeted Flow: FNj=NAy+FT+FNq    -   Third Targeted Flow: FNk=NAz+FT+FNr    -   Fourth Targeted Flow: . . .

Flow Merging from A to B and from B to A is independent each other. TheFlow Merging of two half-duplex channels can be symmetrical orasymmetrical. All of these elements will be mapped to CS control framein the above order. Flow Merging_Response Frame uses two parameters:Flow_Merging_successful or Flow_Merging_unsuccessful shown in the Table24. TABLE 24 Parameters of Flow Merging_Response Frame CS Frame TypesCodes Flow_Merging_successful Binary “00000001 00011001 0000000100000000” Flow_Merging_unsuccessful Binary “00000001 00011010 0000000100000000”Note 1: Operation of Control frame for flow between MAC and client willbe implemented via MA_Data Request and Indication primitives.

Flow Merging can be used to operations of half duplex point-to-point andfull duplex point-to-point.

12.3 Flow Based Security—Line-Speed Filtering

The MSF entity provides a Line-Speed Filtering Function Unit (LSFFU) ofFlow based to Content-Aware frame classification, which enables a nodeprocessing application to filter and classify frames based on certainprotocol fields of upper layer in the payload of frame. Filters can beset on the defined fields from Layer 2 to Layer 4 within a frame. LSFFUof a node can filter individual ingress or egress ports of Flow.Filtering algorithm uses two constructs, (a) the filter mask, whichdefines which fields to filter, and (b) the rules table, which definesthe filtering options. Up to 48 filters are available, each containing a64-octet wide shuttered filter mask value to apply on any protocol fieldat any offset within the first 96 octets of the incoming frame. The ruletable is up to 256 entries deep for TCE Flow.

Once the classification results and filter match or partial match havebeen gotten, the following policies can be taken, or in theircombination:

-   -   Modification of the IP Type Of Service (TOS precedence) field    -   Delivery of a copy of the related frames to the domain of        management    -   Discarding the related frames    -   Transferring the related frames to other egress port of a Flow    -   Transmission of a copy of the related frames to the “mirrored        to” Flow    -   Modification of protocol field

The LSFFU provides the ability to track and profile up to 1024 dataflows. The traffic on these data flows can be monitored or regulated viainternal meters and has the ability to assign two independent policiesto the profile status of a data flow and execute these actions at linerate.

The CS operational codes of Line-Speed Filtering are listed in the Table25. TABLE 25 Codes of Line-Speed Filtering frame CS Frame Types CodesLine-Speed Filtering_Request Frame 00110011 Line-SpeedFiltering_Response Frame 00110100Note 1: Operation of Control frame for flow between MAC and client willbe implemented via MA_Data Request and Indication primitives.

The parameter of Line-Speed Filtering Request Frame includes thefollowing elements:

-   -   Targeted Flow: FNi=NAx+FT+FNp    -   Modification of the IP Type Of Service (TOS precedence) field,        binary code: 10000001, the detailed operation is under study.        Otherwise, binary code: 00000000 will be used.    -   Delivery of a copy of the related frames to the domain of        management, binary code: 10000010 represents that action of        “Delivery of a copy of the related frames to the domain of        management” will be taken. Otherwise, binary code: 00000000 will        be used.    -   Discarding the related frames, binary code: 10000011 represents        that action of “Discarding the related frames” will be taken.        Otherwise, binary code: 00000000 will be used.    -   Transferring the related frames to other egress port of a Flow,        binary code: 10000100 represents that action of “Transferring        the related frames to other egress port of a Flow (This Flow is        presented as FNj=NAx+FT+FNq)” will be taken. So the octet        “10000100” plus “FNj” will be used for this function. Otherwise,        binary code: 00000000 will be used.    -   Modification of protocol field, binary code: 10000101, the        detailed operation is under study. Otherwise, binary        code:00000000 will be used.

Line-Speed Filtering from A to B and from B to A is independent eachother. The Line-Speed Filtering of two half-duplex channels can beselected to use or not use. All of these elements will be mapped to CSframe in the above order. Line-Speed Filtering_Response Frame uses twoparameters: Line-Speed Filtering successful or Line-Speed Filteringunsuccessful shown in the Table 26. TABLE 26 Parameters of Line-SpeedFiltering_Response Frame CS Frame Types CodesLine-Speed_Filtering_successful Binary “00000001 00011011 0000000100000000” Line-Speed_Filtering_unsuccessful Binary “00000001 0001110000000001 00000000”Note 1: Operation of Control frame for flow between MAC and client willbe implemented via MA_Data Request and Indication primitives.

Flow Merging can be used to point-to-point operations of both halfduplex and full duplex.

13 Topology Application of Link-Type, Broadcast Network and Pseudo-Mesh

13.1 Support of a Link-Type with Adding and Dropping Flow Services

In some application, it is needed to build a link-type topology shown inthe FIG. 16 in which the connection between Node 2 and Node 4 (it issuppositional) is one or more Flows. This Flow may be a Flow of otherMSF. If the topology is involved in FIG. 16, steering and wrapping, datanode insertion and deletion, fairness should not be used. Instead, thesefunctions will be switched off via configuration function of the networkmanagement. Link-type Network bi-directional can be supported by RPR MACdepending on topology/protection mechanisms being disabled.MA_DATA.request is currently specified to allow a packet to be sent withWrap Disable, Protection Disable, and Steering Disable by explicitlyrequesting a particular ringlet with no protection. Requires furtherstudy to determine if other MAC mechanisms would prevent this requestfrom being fulfilled. The data and control packet will share the samechannel and RI (Ringlet Identifier) field is always set to “0”.

FIG. 16 Shows a MSF Topology, Link-Type with Adding and Dropping FlowServices.

FIG. 17 Shows a MSF Topology, Broadcast Connection to DVB Application.

FIG. 18 Shows a MSF Topology, Pseudo-Mesh Connection.

13.2 Support of a Broadcast Connection to DVB Application

In DVB application for example, it is needed to build a broadcastnetwork topology shown in the FIG. 17 in which the connections from Node1 to Node 2/3/4 are trunk pipes of single direction. If the topology isinvolved in FIG. 17, the protection switch of trunk pipe based, steeringand wrapping, data node insertion and deletion, Flow based Protectionand in-band network management should not be used. Instead, thesefunctions will be switched off via configuration function of the networkmanagement. Broadcast Network—unidirectional may be supported by RPR MACdepending on topology/protection mechanisms being disabled.MA_DATA.request is currently specified to allow a packet to be sent withWrap Disable, Protection Disable, and Steering Disable by explicitlyrequesting a particular ringlet with no protection. Requires furtherstudy to determine if other MAC mechanisms would prevent this requestfrom being fulfilled. The data and control packet will share the samechannel and RI (Ringlet Identifier) field is always set to “0”.

13.3 Support of a Pseudo-Mesh Topology

Pseudo-mesh Topology presented in FIG. 18 is a particular example of atwo-fibre ring. Eight Nodes via trunk pipe are attached together to forma ring. The Flows of Node 2, 4, 6 and 8 are connected to the Node 9 (itis suppositional) by flows. In this application, all function andspecifications defined in this Patent can be used effectively. Flowcross-connection is concentrated and scheduled on the Node 9.

INDUSTRIAL APPLICABILITY

The present invention can provide the following capabilities:

-   (1) The Technology encapsulation and transport of Ethernet, Frame    Relay, G.702 PDH circuit—Synchronous and asynchronous circuit    transport, Video signal, voice-band signal, Digital channel    supported by 64 kbit/s-based ISDN etc over a two-fibre ring, a    link-type and broadcast topology of fibres.-   (2) Service (or flow) based protection of 1+1, 1:1, and 1:N models    within 50 ms.-   (3) Service (or flow) based multicast and station-based multicast    and broadcast.-   (4) Bandwidth limitation of service (or flow) based with symmetry    and asymmetry.-   (5) Flow merging with symmetry and asymmetry.-   (6) Line-speed filtering of flow based.-   (7) Flow based performance monitoring in 15-minute and 24-hour.-   (8) Mirroring of flow.-   (9) Frame based transparent PPPoE and PPPoA transport from access to    backbone along a MSF ring or other topologies, in order to simplify    accounting mechanism (e.g. Radius), reduce maintenance work, and    improve latency variation (compared to Layer 2 and Layer 3 switch)    in Access network application.

It is to be understood that the above descriptions should not beconstrued as limitations on the scope of the invention, but rather as anexemplification of preferred embodiments thereof. Accordingly, the scopeof the invention should be determined by the appended claims and theirequivalents. Any variations or modifications within the spirit and scopeof the invention are covered by the appended claims.

1. A data transmission apparatus for implementing multiple service flowin a multiple service ring including a trunk pipe and at least two nodeseach with at least one flow, said apparatus comprising: a flow Rx framercoupled to said flows for converting data received from said flows intodata packets of a predetermined protocol; transmission setup module forsetting-up information indicating the destination node address anddestination flow for packets of said predetermined protocol to betransmitted; and a Tx framer for encapsulating said informationindicating the destination node address and destination flow and thepackets of said predetermined protocol into frames of the multipleservice ring and transmitting the same along said trunk pipe to adownstream neighbour node along the ring.
 2. The data transmissionapparatus according to claim 1, wherein said predetermined protocol is aXP (processing protocol), and said apparatus further comprising: a Rxframer for receiving and de-framing data frames of the multiple servicering from a upstream neighbor node along said trunk pipe to obtain atleast a destination node address and XP packets; and transiting modulefor transiting the frames destined to other nodes to said Tx framer soas to forward the frames destined to other nodes to a next node.
 3. Thedata transmission apparatus according to claim 2, further comprising: adestination flow determining module for determining a destination flowof the XP packets for a Universally or locally administered address; anda flow Tx framer for converting said XP packets for a node with aUniversally or Locally administered address from the Rx framer into dataof format of local flow and sending the local flow data to acorresponding flow determined by said destination flow determiningmodule.
 4. The data transmission apparatus according to claim 1, whereinsaid transiting module transits the frames destined to other nodes at afast and almost fixed rate.
 5. The data transmission apparatus accordingto claim 1, wherein said multiple service ring is a dual-ring structureconsisting of a pair of unidirectional count-rotating ringlets, saidmultiple service flow is based on RPR, and said Rx framer is RPR Rxframer and said Tx framer is RPR Tx framer.
 6. The data transmissionapparatus according to claim 3, wherein said destination flowdetermining module includes a discriminator for determining whether saidreceived packets for a node with a Universally or Locally administeredaddress are unicast, multicast or broadcast; a flow member copyingmodule for making copies of the packets for each of the correspondingflow if multicast or broadcast is determined within a membership groupin a node; and flow identifier determining module for determiningdestination flow from FT and FN fields in the received frames.
 7. Thedata transmission apparatus according to claim 6, wherein saidtransmission setup module sets up destination node address(NA), and FTand FN fields for indicating the type and NO. of the destination flow.8. The data transmission apparatus according to claim 7, furthercomprising a Tx schedule unit for scheduling the transmission of dataframes according to a priority of the frames, and decide which framewill go first to the downstream along the ringlet.
 9. The datatransmission apparatus according to claim 8, further comprising a flowbased protection (FBP) unit for performing flow based protection toprovide at least one flow to be used as a standby in case of failure ofthe used flows.
 10. The data transmission apparatus according to claim9, wherein said FBP unit provides 1+1 FBP to designate a mate StandbyFlow with the same service property, source and sink in which payloadsof the mate Working Flow and Standby Flow carries the same traffic, andOnce FBP occurred for this working flow, said standby will replace thisworking flow within 50 ms.
 11. The data transmission apparatus accordingto claim 9, wherein said FBP unit provides 1:1 FBP to designate a mateStandby Flow with the same service property, source and sink in whichpayloads of the Standby Flow can run the other additional traffic, andonce FBP occurred for this Working Flow, the additional traffic will bedropped out within 50 ms.
 12. The data transmission apparatus accordingto claim 9, wherein said FBP unit provides 1:N FBP to designate a mateStandby Flow with the same service property, source and sink in whichpayloads of the Standby Flow runs the other additional traffic, and onceFBP in one of N Working Flow occurred, this additional traffic will bedropped out within 50 ms.
 13. The data transmission apparatus accordingto claim 9, wherein said FBP unit is for one of Ethernet and TCE. 14.The data transmission apparatus according to claim 13, wherein said MSFuses Fairness arithmetic and supports both local address and global nodeaddress, said local address is PLAS that is an address of node link onthe MSF ring and has local meaning only along the MSF ring.
 15. The datatransmission apparatus according to claim 7, further comprising a framesequence number generator for generating frame sequence numbersequentially with respect to a specified modulus for each of the dataframes to be transmitted at the transmitting side; and at the receivingside, a FSN extractor for extracting a FSN with respect to apeer-to-peer modulus from the received data frames; a counter at thereceiving side for counting the number of the received data frames; anda comparator for comparing the counted frame number with the extractedFSN, if mismatch, an error reflecting transport performance isindicated.
 16. The data transmission apparatus according to claim 15,wherein said destination flow determining module gets at lease one ofPT, PFI, a value of FT/CS/NM, FN and FSN from the received frames fromthe upstream node, and said transmission setup module attaches PT, PFI,a value of FT/CS/NM, FN and FSN into the data frames to be transmitted.17. The data transmission apparatus according to claim 16, wherein saidRPR Rx framer, RPR Tx framer and the transiting module are of IEEE802.17 MAC layer; said flow Rx framer, said transmission setup module,and said destination flow determining module, said FSN generator, FSNextractor, counter, comparator, and flow Tx framer are of the XP layer.18. The data transmission apparatus according to claim 17, furthercomprising a flow adaptation function unit having functions of thesignal and rate transform, synchronous function between flow Rx/Txframer and flow service interface, and said flow adaptation functionunit is of a flow processing layer.
 19. The data transmission apparatusaccording to claim 18, wherein said flow processing layer is a upperlayer of said XP layer, said XP layer is a upper layer of said IEEE802.17 MAC layer, and corresponding interfaces are provided between therespective layers.
 20. The data transmission apparatus according toclaim 17, further comprising a shaper for generating a rate-limitingindication so as to reject excessive transmissions and avoid overflow,and said shaper is of XP layer.
 21. The data transmission apparatusaccording to claim 3, wherein said frame includes at lease one of a RPRheader field, Extended protocol field, PT field, PFI field, Reservedfields, FT/CS/NM field, FN field, FSN field, HEC field, payload of XP,and XP payload FCS.
 22. The data transmission apparatus according toclaim 3, wherein a network of said MSF is divided into a XP layernetwork that provides the transport of adapted information through a XPtrail between XP access points and a MDL layer network that provides thetransport of adapted information through a MDL trail between accesspoints.
 23. The data transmission apparatus according to claim 22,further comprising a co-located XP trail termination source and sinkpair, said XP trail termination source accepts adapted information atits input, adds the flow traffic, inserts CS or NM packets and presentsthe characteristic information of the XP layer network at its output,and said XP trail termination sink accepts the characteristicinformation of the XP layer network at its input, terminates the flowtraffic, extracts the CS or NM packets and presents the adaptedinformation at its output, wherein said XP trail termination source andsink pair is of XP layer network.
 24. The data transmission apparatusaccording to claim 22, further comprising a co-located MDL trailtermination source and sink pair, said MDL trail termination sourceaccepts adapted information at its input, inserts CS or NM packets andpresents the characteristic information of the MDL layer network at itsoutput, said MDL trail termination sink accepts the characteristicinformation of the MDL layer network at its input, removes the CS or NMpackets and presents the adapted information at its output, wherein saidMDL trail termination source and sink pair is of MDL layer network. 25.The data transmission apparatus according to claim 22, wherein said MSFnetwork provides the information transfer capability required to supportvarious types of services of different bit rates by various serverlayers, and offers a XP trail and uses the XP trail in a server layernetwork.
 26. The data transmission apparatus according to claim 22,further comprising a co-located pair of XP/Client adaptation source andsink, said XP/Client adaptation source performs the function of AddingXP header between its input and its output, and said XP/Clientadaptation sink performs the function of Remove XP header between itsinput and its output.
 27. The data transmission apparatus according toclaim 22, further comprising a co-located pair of MDL/XP adaptationsource and sink, said MDL/XP adaptation source performs the functions ofpacket multiplexing and adding MDL header between its input and itsoutput, and said MDL/XP adaptation sink performs the functions of packetde-multiplexing according to flow number value and MDL header extractionbetween its input and its output.
 28. The data transmission apparatusaccording to claim 22, wherein said MSF network provides apoint-to-multipoint MDL Network Connection/Flow that multicasts customertraffic from single node to a group of nodes; and a point-to-multipointXP Network Connection that multicasts customer traffic within a singlenode, from an MDL/XP adaptation sink to multiple XP/Server adaptationsinks.
 29. The data transmission apparatus according to claim 1, whereinsaid flows include at least one of Ethernet, TDM Circuit Emulationincluding the emulation of G.707 SDH circuit—Transport of TU-11, TU-12or TU-2, G.702 PDH circuit—Synchronous and asynchronous circuittransport, Video signal, Voiceband signal, Digital channel supported by64 kbit/s-based ISDN, and an trunk pipe of other MSR span with a lowerrate than that of this trunk pipe.
 30. The data transmission apparatusaccording to claim 1, further comprising: a flow based multicasting unitfor duplicating data frames from a source flow getting a payload of theframe to other multiple flows with the same FT field value within anode.
 31. The data transmission apparatus according to claim 1, furthercomprising: a bandwidth limitation unit for providing bandwidthlimitation to a specific flow.
 32. The data transmission apparatusaccording to claim 1, further comprising: a merging unit for mergingplural flows of the same FT field value to form a flow merging group(FMG) similar to one logical link.
 33. The data transmission apparatusaccording to claim 1, further comprising: a line speed filtering unitfor filtering and classifying frames based on certain protocol fields ofupper layer in the payload of frame.
 34. The data transmission apparatusaccording to claim 1, further comprising: a flow mirroring unit formonitoring the incoming or outgoing traffic on a related flow byconnecting a sniffer to a “mirrored to” flow.
 35. A multiple servicering system comprising a plurality of nodes, each node including a datatransmission apparatus according to claim 1, wherein each of said nodesis assigned a node address(NA), and data incoming to a node contains adestination node address, and said destination node address is XOR'edwith the NA of node with a Universally or Locally administered addressto check for match or mismatch.
 36. The system according to claim 35,wherein an external timing source is provided to one of the nodes alongthe ring, and the other nodes make reference to the timing signalingfrom said one node for synchronization.
 37. The system according toclaim 36, wherein said nodes are coupled in a double fibre ring or asingle fibre ring.
 38. The system according to claim 36, wherein one ofthe nodes is only coupled to another node with a flow.
 39. The systemaccording to claim 36, wherein one of the nodes forms broadcastingconnection to other nodes with trunk pipes in a DVB application.
 40. Thesystem according to claim 36, wherein one of the nodes is only coupledto each of the other nodes with a flow to form a pseudo-mesh connectionwhile other four nodes are connected to form a two-fibre ring.
 41. Adata transmission method for implementing multiple service flow in amultiple service ring including a trunk pipe and at least two nodes eachwith at least one flow, said method comprising: a flow Rx framing stepof receiving data from a flow and converting the received data into datapackets of a predetermined protocol; a transmission setup step ofsetting-up information indicating the destination node address anddestination flow for packets of said predetermined protocol to betransmitted; and a Tx framing step of encapsulating said informationindicating the destination node address and destination flow and thepackets of said predetermined protocol into frames of the multipleservice ring and transmitting the same along said trunk pipe to adownstream neighbour node along the ring.
 42. A data transmission methodaccording to claim 41, wherein said predetermined protocol is aXP(processing protocol), and said method further comprising: a Rxframing of receiving and de-framing data frames of the multiple servicering from a upstream neighbor node along said trunk pipe to obtain atleast a destination node address and XP packets; and a transiting stepof transiting the frames destined to other nodes so as to forward theframes destined to other nodes to a next node.
 43. A data transmissionmethod according to claim 42, further comprising: a destination flowdetermining step of determining a destination flow of the XP packets fora node with a Universally or Locally administered address; and a flow Txframing step of converting said XP packets for node with a Universallyor Locally administered address into data of format of local flow andsending the local flow data to a corresponding flow determined in saiddestination flow determining step.
 44. The data transmission methodaccording to claim 41, wherein said transiting step transits the framesdestined to other nodes at a fast and almost fixed rate.
 45. The datatransmission apparatus according to claim 41, wherein said multipleservice ring is a dual-ring structure consisting of a pair ofunidirectional count-rotating ringlets, said multiple service flow isbased on RPR.
 46. The data transmission method according to claim 43,wherein said destination flow determining step includes a discriminatingstep of determining whether said received packets for a node with aUniversally or Locally administered address are unicast, multicast orbroadcast; a flow member copying step of making copies of the packetsfor each of the corresponding flow if multicast or broadcast isdetermined within a membership group in a node; and flow identifierdetermining step of determining destination flow from FT and FN fieldsin the received frames.
 47. The data transmission method according toclaim 46, wherein said transmission setup step sets up destination nodeaddress(NA), and FT and FN fields for indicating the type and NO. of thedestination flow.
 48. The data transmission method according to claim47, further comprising a Tx scheduling step before the TX framing stepfor scheduling the transmission of data frames according to a priorityof the frames, and decide which frame will go first to the downstreamalong the ringlet.
 49. The data transmission method according to claim48, further comprising a flow based protection (FBP) step for performingflow based protection to provide at least one flow to be used as astandby in case of failure of the used flows.
 50. The data transmissionmethod according to claim 49, wherein said FBP step provides 1+1 FBP todesignate a mate Standby Flow with the same service property, source andsink in which payloads of the mate Working Flow and Standby Flow carriesthe same traffic, and once FBP occurred for this working flow, saidstandby will replace this working flow within 50 ms.
 51. The datatransmission method according to claim 49, wherein said FBP stepprovides 1:1 FBP to designate a mate Standby Flow with the same serviceproperty, source and sink in which payloads of the Standby Flow can runthe other additional traffic, and once FBP occurred for this WorkingFlow, the additional traffic will be dropped out within 50 ms.
 52. Thedata transmission method according to claim 49, wherein said FBP stepprovides 1:N FBP to designate a mate Standby Flow with the same serviceproperty, source and sink in which payloads of the Standby Flow runs theother additional traffic, and once FBP in one of N Working Flowoccurred, this additional traffic will be dropped out within 50 ms. 53.The data transmission method according to claim 49, wherein said FBPstep is for one of Ethernet and TCE.
 54. The data transmission methodaccording to claim 53, wherein said MSF uses Fairness arithmetic andsupports both local address and global node address, said local addressis PLAS that is an address of node link on the MSF ring and has localmeaning only along the MSF ring.
 55. The data transmission methodaccording to claim 47, further comprising a frame sequence numbergenerating step of generating frame sequence number sequentially withrespect to a specified modulus for each of the data frames to betransmitted at the transmitting side; and at the receiving side, a FSNextracting step of extracting a FSN with respect to a peer-to-peermodulus from the received data frames; a counting step at the receivingside of counting the number of the received data frames; and a comparingstep of comparing the counted frame number with the extracted FSN, ifmismatch, an error reflecting transport performance is indicated. 56.The data transmission method according to claim 55, wherein saiddestination flow determining step gets at lease one of PT, PFI, a valueof FT/CS/NM, FN and FSN from the received frames from the upstream node,and said transmission setup step attaches PT, PFI, a value of FT/CS/NM,FN and FSN into the data frames to be transmitted.
 57. The datatransmission method according to claim 56, wherein said Rx framing step,Tx framing step and the transiting step are of IEEE802.17 MAC layer;said flow Rx framing step, said transmission setup step, and saiddestination flow determining step, said FSN generating step, FSNextracting step, counting step, comparing step, and flow Tx framing stepare of the XP layer.
 58. The data transmission method according to claim57, further comprising a flow adaptation function of the signal and ratetransform, synchronous function between two sides of peer, and said flowadaptation function is of a flow processing layer.
 59. The datatransmission method according to claim 58, wherein said flow processinglayer is a upper layer of said XP layer, said XP layer is a upper layerof said IEEE802.17 MAC layer, and corresponding interface functions areprovided between the respective layers.
 60. The data transmission methodaccording to claim 57, further comprising a shaping step of generating arate-limiting indication so as to reject excessive transmissions andavoid overflow, and said shaping step is of XP layer.
 61. The datatransmission method according to claim 43, wherein said frame includesat least one of a RPR header field, Extended protocol field, PT field,PFI field, Reserved fields, FT/CS/NM field, FN field, FSN field, HECfield, payload of XP, and XP payload FCS.
 62. The data transmissionmethod according to claim 43, wherein a network of said MSF is dividedinto a XP layer network that provides the transport of adaptedinformation through a XP trail between XP access points and a MDL layernetwork that provides the transport of adapted information through a MDLtrail between access points.
 63. The data transmission method accordingto claim 62, further comprising a XP trail termination source step ofaccepting adapted information when inputting, adding the flow traffic,inserting CS or NM packets and presenting the characteristic informationof the XP layer network when outputting, and a XYP trail terminationsink step of accepting the characteristic information of the XP layernetwork when inputting, terminating the flow traffic, extracting the CSor NM packets and presenting the adapted information when outputting,wherein said XP trail termination source step and sink step are of XPlayer network.
 64. The data transmission method according to claim 62,further comprising a MDL trail termination source step of acceptingadapted information when inputting, inserting CS or NM packets andpresenting the characteristic information of the MDL layer network whenoutputting, and a MDL trail termination sink step of accepting thecharacteristic information of the MDL layer network when inputting,removing the CS or NM packets and presenting the adapted informationwhen outputting, wherein said MDL trail termination source step and sinkstep are of MDL layer network.
 65. The data transmission methodaccording to claim 62, wherein said MSF network provides the informationtransfer capability required to support various types of services ofdifferent bit rates by various server layers, and offers a XP trail anduses the XP trail in a server layer network.
 66. The data transmissionmethod according to claim 62, further comprising a XP/Client adaptationsource step of performing the function of adding XP header between theinputting and outputting, and a XP/Client adaptation sink step ofperforming the function of remove XP header between the inputting andoutputting.
 67. The data transmission method according to claim 62,further comprising a MDL/XP adaptation source step of performing thefunctions of packet multiplexing and adding MDL header between itsinputting and its outputting, and a MDL/XP adaptation sink step ofperforming the functions of packet de-multiplexing according to flownumber value and MDL header extraction between its inputting and itsoutputting.
 68. The data transmission method according to claim 62,wherein said MSF network provides a point-to-multipoint MDL NetworkConnection/Flow that multicasts customer traffic from single node to agroup of nodes; and a point-to-multipoint XP Network Connection thatmulticasts customer traffic within a single node, from an MDL/XPadaptation sink to multiple XP/Server adaptation sinks.
 69. The datatransmission method according to claim 41, wherein said flows include atleast one of Ethernet, TDM Circuit Emulation including the emulation ofG.707 SDH circuit—Transport of TU-11, TU-12 or TU-2, G.702 PDHcircuit—Synchronous and asynchronous circuit transport, Video signal,Voiceband signal, Digital channel supported by 64 kbit/s-based ISDN, andan trunk pipe of other MSR span with a lower rate than that of thistrunk pipe.
 70. The data transmission method according to claim 41,further comprising: a flow based multicasting step of duplicating dataframes from a source flow getting a payload of the frame to othermultiple flows with the same FT field value within a node.
 71. The datatransmission method according to claim 41, further comprising: abandwidth limiting step of providing bandwidth limitation to a specificflow.
 72. The data transmission method according to claim 41, furthercomprising: a merging step of merging plural flows of the same FT fieldvalue to form a flow merging group(FMG) similar to one logical link. 73.The data transmission method according to claim 41, further comprising:a line speed filtering step of filtering and classifying frames based oncertain protocol fields of upper layer in the payload of frame.
 74. Thedata transmission method according to claim 41, further comprising: aflow mirroring step of monitoring the incoming or outgoing traffic on arelated flow by connecting a sniffer to a “mirrored to” flow.